Вопрос по хешированию таблицы базы данныm

[imhoneer]

Господа перерыл весь интернет, но так и не смог найти ответ на свой вопрос. Поэтому, если есть возможность, то прошу вашего ответа.

Итак у нас есть только одна таблица базы данных вида:

id/            adress           /summ/name        /
1/77rteyueruerurturrurtuy/70     /NULL        /
2/75rteyuerue55rturrurtuf/100    /Detskii Mir/

и таких строк около миллиарда.

Можно ли в течении 1 минуты получить хеш всей этой таблицы?

[1715599914]

1715599914

[kcaterpillar]

Господа перерыл весь интернет, но так и не смог найти ответ на свой вопрос. Поэтому, если есть возможность, то прошу вашего ответа.

Итак у нас есть только одна таблица базы данных вида:

id/            adress           /summ/name        /
1/77rteyueruerurturrurtuy/70     /NULL        /
2/75rteyuerue55rturrurtuf/100    /Detskii Mir/

и таких строк около миллиарда.

Можно ли в течении 1 минуты получить хеш всей этой таблицы?

Нужно считать. Вполне вероятно, что можно. Хэши (хэш-функции) бывают разные, требуют разное время для вычисления. поэтому нужно говорить конкретнее, какая будет использоваться хэш-функция. Также конечно всё зависит от вычислительной мощности машины, процессора. Эту задачу можно выполнять в многопоточном режиме, поэтому скорость можно увеличить в разы при многопроцессорном вычислении. Также имеет значения скорость выборки из базы - какая база, какой сервер базы данных, с какой скорость происходит выборка 1 миллиарда записей? Во многих базах есть встроенный функционал подобных вычислений. Поэтому нужно конкретно всё это проанализировать и посчитать.  Теоритически посчитать хэш миллиарда подобных записей за минуту вполне возможно.

[imhoneer]

Нужно считать. Вполне вероятно, что можно. Хэши (хэш-функции) бывают разные, требуют разное время для вычисления. поэтому нужно говорить конкретнее, какая будет использоваться хэш-функция. Также конечно всё зависит от вычислительной мощности машины, процессора. Эту задачу можно выполнять в многопоточном режиме, поэтому скорость можно увеличить в разы при многопроцессорном вычислении. Также имеет значения скорость выборки из базы - какая база, какой сервер базы данных, с какой скорость происходит выборка 1 миллиарда записей? Во многих базах есть встроенный функционал подобных вычислений. Поэтому нужно конкретно всё это проанализировать и посчитать.  Теоритически посчитать хэш миллиарда подобных записей за минуту вполне возможно.

Хорошо тогда я задам вопрос по конкретнее. Хеш всей данной таблицы нужен чтобы завиксировать или появления/удаления новых строк или изменения балансов.

Т.е. чисто теоретически можно ли создать такое хеширование, которое заменило бы блокчейн. Т.е. транзакции для одного блока прошли, этот блок всеми одобрен. Транзакции зафиксировались в таблице, произошли изменения балансов, строк, названий. Получили текущий хеш таблицы, взяли предыдущий хеш и прохешировали (как у блокчейна с блоками транзакций).

[kcaterpillar]

Хорошо тогда я задам вопрос по конкретнее. Хеш всей данной таблицы нужен чтобы завиксировать или появления/удаления новых строк или изменения балансов.

Т.е. чисто теоретически можно ли создать такое хеширование, которое заменило бы блокчейн. Т.е. транзакции для одного блока прошли, этот блок всеми одобрен. Транзакции зафиксировались в таблице, произошли изменения балансов, строк, названий. Получили текущий хеш таблицы, взяли предыдущий хеш и прохешировали (как у блокчейна с блоками транзакций).

Да, конечно можно, и всё это уже давно делается, задолго до биткойнов. Это называется контроль целостности данных.  Во многих базах данных есть встроенный функционал для этого. Собственно, в биткойн алгоритм отличается лишь тем, что система распределённая и есть механизм POW - т.е. сложности, трудности быстрого изменения этих хэшей (и данных соответственно).

Но важно, в какой базе вы храните данные. Во всех серьезных базах можно измерить скорость выборки для 1 млрд. записей. Затем, зная объём всех данных и производительность вашей машины для конкретной выбранной хэш-функции, вы легко сосчитаете время выполнения вашей задачи - т.е. время выборки плюс время для вычисление хэша.

Если немного изменить алгоритм, можно использовать параллельные вычисления, это даст возможность увеличить производительность во много раз, при наличии вычислительных мощностей (много процессоров или ASIC).

[imhoneer]

Да, конечно можно, и всё это уже давно делается, задолго до биткойнов. Это называется контроль целостности данных.  Во многих базах данных есть встроенный функционал для этого. Собственно, в биткойн алгоритм отличается лишь тем, что система распределённая и есть механизм POW - т.е. сложности, трудности быстрого изменения этих хэшей (и данных соответственно).

Т.е. я так понимаю, что уже сейчас это реально.

Итак у нас есть быстрая база данных вида, как я описывал выше. К нам приходит блок с транзакциями одобренных всей сетью (алгоритм консенсуса пока не важен, т.к. мы говорим именно, что сам консенсус установлен). Мы проходимся по базе данных и вносим изменения. После этого хешируем нашу таблицу, получаем хеш, соединяем предыдущий хеш с текущим и сново хешируем. Делаем проверку с сетью получившегося хеша, если все нормально, то оставляем только этот хеш и нашу измененную базу данных.

Это ж какая экономия по памяти для блокчейна будет.

[kcaterpillar]

Т.е. я так понимаю, что уже сейчас это реально.

Итак у нас есть быстрая база данных вида, как я описывал выше. К нам приходит блок с транзакциями одобренных всей сетью (алгоритм консенсуса пока не важен, т.к. мы говорим именно, что сам консенсус установлен). Мы проходимся по базе данных и вносим изменения. После этого хешируем нашу таблицу, получаем хеш, соединяем предыдущий хеш с текущим и сново хешируем. Делаем проверку с сетью получившегося хеша, если все нормально, то оставляем только этот хеш и нашу измененную базу данных.

Это ж какая экономия по памяти для блокчейна будет.

Насколько я понял, вы хотите держать в базе данных только итоговый баланс по каждому адресу? А сами транзакции не хранить. Такие программы уже сделаны и для биткойна тоже, но они не в общественном доступе. Всё это вполне реально. Но имейте в виду, что у вас хранится только сумма на счету, а вот распечатку - историю всех транзакций счёта вы по своей базе уже не сделаете. Поэтому и памяти меньше требуется.  В целом, стандартный клиент биткойна, например, избыточных данных особо не содержит, но он хранит всю информацию о системе, поэтому столько съедает памяти.

[imhoneer]

Насколько я понял, вы хотите держать в базе данных только итоговый баланс по каждому адресу? А сами транзакции не хранить. Такие программы уже сделаны и для биткойна тоже, но они не в общественном доступе. Всё это вполне реально. Но имейте в виду, что у вас хранится только сумма на счету, а вот распечатку - историю всех транзакций счёта вы по своей базе уже не сделаете. Поэтому и памяти меньше требуется.  В целом, стандартный клиент биткойна, например, избыточных данных особо не содержит, но он хранит всю информацию о системе, поэтому столько съедает памяти.

Да, Вы именно правильно поняли. Я рад, что такие вещи уже есть. Однако для полных нод Биткоина такой блокчейн именно не подойдет, по причине того, что биткоин реализован на алгоритме консенсуса POW. В котором предусмотрено постоянное появление форков и побеждает именно самая длинная цепочка. Если же криптовалюта будет реализована на другом алгоритме консенсуса, например, на POA https://bitcointalk.org/index.php?topic=1934810.0 где предусмотрен однозначный результат и форки исключены, то это именно то что нужно, т.к. нет смысла хранить историю всех транзакций.

Спасибо, что помогли разобраться с вопросом.

[GGUL]

Если в одной записи будет порядка 100 байт * миллиард записей ~ 100Гб данных.
Прокачать с диска на обычном компьютере за минуту  - нереально.

[imhoneer]

Если в одной записи будет порядка 100 байт * миллиард записей ~ 100Гб данных.
Прокачать с диска на обычном компьютере за минуту  - нереально.

Понял. Хочу спросить, а может в некоторых базах есть контрольные суммы, которые могут меняться хотя бы при изменении одного символа, тогда можно было бы хешировать эти суммы, а не всю базу данных.


Я вот тут в Гугле порылся и откапал неплохую темку "Как посчитать контрольную сумму?" https://php.ru/forum/threads/kak-poschitat-kontrolnuju-summu.8039/ Вроде все реально, поэтому кому интересно почитайте.

[kcaterpillar]

Если в одной записи будет порядка 100 байт * миллиард записей ~ 100Гб данных.
Прокачать с диска на обычном компьютере за минуту  - нереально.

На обычном компьютере может и нереально, а на хорошем сервере базы данных вполне реально. Они делают и терабайтные выборки за это время.  Об этом уже писал, что время выборки будет весьма критичным, в зависимости от оборудования и базы данных, поэтому нужно это учесть и протестировать. Скорость выборки из конкретной таблицы проверяется легко, все нормальные базы имеют такой функционал. К тому же возможна и оптимизация при выборке, тут много вариантов, но всё это вполне реально сделать.

Понял. Хочу спросить, а может в некоторых базах есть контрольные суммы, которые могут меняться хотя бы при изменении одного символа, тогда можно было бы хешировать эти суммы, а не всю базу данных.

Да, в базах данных есть встроенный функционал для контроля изменений данных в таблице. Также это всё можно и запрограммировать в базе данных.  Контрольная сумма это и есть хэш-функция, это синонимы в этом смысле. Хэш-функция изменит своё значение  не только при изменении одного символа входных данных, а при изменении даже одного бита.

Как уже говорил, можно оптимизировать процесс - сделать многопоточную обработку данных, разделить таблицу на несколько секций - такая возможность есть в базах, причём можно обращаться с запросами как к отдельным секциям, так и ко всей таблице. Храниться физически они могут даже на разных машинах. Вычислять хэш могут несколько потоков. Для вашей задачи это вполне подойдёт, вы можете заранее знать, где какой адрес лежит - в какой секции, и вычислять и сравнивать хэш именно в ней. И также быстро вычислять суммарный хэш для всех таблиц.

[kcaterpillar]

Да, и в мощных базах данных база сама помнит, какую запись и где она изменяла или вносила новые записи, в какое время, и так далее. Т.е. вы простым запросом за миллисекунду узнаете, где были последние изменения, соответственно там можно вычислить новый хэш. В БД есть очень мощный функционал, и в базе можно программировать все эти правила. Так же всё можно оптимизировать. Ваша задача вполне выполнима.

[imhoneer]

Да, и в мощных базах данных база сама помнит, какую запись и где она изменяла или вносила новые записи, в какое время, и так далее. Т.е. вы простым запросом за миллисекунду узнаете, где были последние изменения, соответственно там можно вычислить новый хэш. В БД есть очень мощный функционал, и в базе можно программировать все эти правила. Так же всё можно оптимизировать. Ваша задача вполне выполнима.

Большое спасибо за ответ.

[GGUL]

В лоб всю таблицу захешировать будет долго. Можно оптимизировать.
Если таблица растет только снизу по порядковому номеру, то можно разбить на пачки по 1000 записей (1млн. пачек). Вычислить хеши каждой пачки и запомнить в отдельной таблице. И от них посчитать хеш всей таблицы

Новых блок изменит значения примерно 10 тысяч адресов. Надо будет пересчитать только хеши тех пачек, куда эти адреса попали.  Для этого потребуется загрузить максимум 10000 пачек*1000строк*100байт - 1ГБ данных. Что выглядит уже более реально.  (вместо 100гб)

Это первое, что пришло в голову. Думаю, что далеко не самый оптимальный.
Может стоить почитать литературу, наверняка, такие алгоритмы уже разработаны.

[imhoneer]

Может стоить почитать литературу, наверняка, такие алгоритмы уже разработаны.

В этой теме https://bitcointalk.org/index.php?topic=1949631.0 я предлагаю новую криптовалюту с новым алгоритмом консонсуса POA и измененным блокчейном. Именно здесь я и спрашивал, а возможно ли такое. Теоретическая возможность есть, если не получиться, то не проблема вернуться к старому надежному блокчейну обычного типа.

[ateregulov]

Господа перерыл весь интернет, но так и не смог найти ответ на свой вопрос. Поэтому, если есть возможность, то прошу вашего ответа.

Итак у нас есть только одна таблица базы данных вида:

id/            adress           /summ/name        /
1/77rteyueruerurturrurtuy/70     /NULL        /
2/75rteyuerue55rturrurtuf/100    /Detskii Mir/

и таких строк около миллиарда.

Можно ли в течении 1 минуты получить хеш всей этой таблицы?

наверное можно, но зачем!? это мне напомнило статью с вредными советами "как достичь хайлоада на ровном месте"

проще делать по технологии снэпшотов - делается хэш начального состояния базы и хэш от операции которую мы хотим применить к базе, потом от этих двух хэшей делаем еще хэш, который будет получен почти мгновенно и будет иметь ту же милу, что и хэш от полной базы

[imhoneer]

наверное можно, но зачем!? это мне напомнило статью с вредными советами "как достичь хайлоада на ровном месте"

проще делать по технологии снэпшотов - делается хэш начального состояния базы и хэш от операции которую мы хотим применить к базе, потом от этих двух хэшей делаем еще хэш, который будет получен почти мгновенно и будет иметь ту же милу, что и хэш от полной базы

Если этот способ делает тоже самое, что я хотел, то можно и так. Смысл именно в модифицированном блокчейне.

Поясните, чем плох такой блокчейн?

[yzoz]

От языка сильно зависит... В Python 3.6 появился весьма быстрый алгоритм BLAKE2

[imhoneer]

От языка сильно зависит... В Python 3.6 появился весьма быстрый алгоритм BLAKE2

В принципе любое быстрое хеширование пойдет, если применять не ко всей базе, а к другому способу хеширования, когда начальное состояние только хешируется, а дальше только хеши операций и общий хеш.

[amaclin]

В принципе любое быстрое хеширование пойдет, если применять не ко всей базе, а к другому способу
хеширования, когда начальное состояние только хешируется, а дальше только хеши операций и общий хеш.

В блокчейне используется меркль-хэш
Я не особо понял в чем его прелесть, но как раз и решается проблема хэширования большого количества
записей (транзакций в блоке) без необходимости пересчета хэша всего блока (мегабайта)
Подробнее расписать не могу, сам не особо въехал.

[imhoneer]

В блокчейне используется меркль-хэш
Я не особо понял в чем его прелесть, но как раз и решается проблема хэширования большого количества
записей (транзакций в блоке) без необходимости пересчета хэша всего блока (мегабайта)
Подробнее расписать не могу, сам не особо въехал.

Смысл дерева меркля - это получения одного хеша из нескольких хешей. Т.е. имеем изначально 4 транзакции, группами по 2 хешируем и получаем 2 хеша, потом эти 2 хеша хешируем и получаем один конечный хеш. Если транзакций нечетное количество, то одна из них клонируется в недостающую группу.

Мне тоже кажется это не совсем рационально, слишком много операций, уверен, что можно как-то сразу сложить хеши всех транзакций и найти конечный хеш.