Мы часто слышим, как продукты для работы с большими данными рекламируют свою хорошую производительность. «Триллионы секунд на поиск» — это распространенная поговорка, которая примерно означает, что данные, соответствующие условиям, могут быть найдены среди триллионов строк данных и могут быть возвращены за секунды.

Это правда?

Прочитав статью «Насколько велик 1Т данных», студенты, участвовавшие в этом выпуске, вероятно, подумали, что это невозможно. Триллионы строк данных должны занимать десятки или сотни терабайт. Если вы хотите обработать их за секунды, вам потребуются десятки тысяч или сотни тысяч жестких дисков. Это нереально.

На самом деле это не так. Второй поиск не обязательно означает полный обход. Если для поиска использовать уникальный идентификационный номер (например, номер телефона, но их не триллионы), то объем вычислений после построения индекса не очень велик. Количество чтений и сравнений составляет около 40 раз. Современный компьютер может. завершить поиск за 1 секунду. Нет необходимости выполнять такой объем вычислений, и даже существует много параллелизма. Вычислительная сложность этой задачи поиска с фиксированной точкой логарифмическая. Объем данных увеличивается с 1 миллиона строк до 1 триллиона строк, а объем вычислений поиска увеличивается только в 2 раза. Неудивительно, что почти все базы данных имеют такую ​​возможность, если их можно сохранить. Конечно, индексация будет медленной, но это уже другая история.

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

Ну в этом вопросе проверить триллионы строк за секунды нереально, но терабайты данных можно. Если всего имеется 100 столбцов данных, и вам нужно прочитать только 1% данных при подсчете одного столбца, это может быть только 10 ГБ. Таким образом, 10 жестких дисков можно просканировать за несколько секунд. для современного серверного кластера — проще простого, быть в 10 раз больше — не проблема.

Наверное, об этом говорит так называемая способность обрабатывать терабайты данных за секунды! Каждый может это сделать.

Есть также некоторые продукты, которые любят сравнивать с известными старыми базами данных, такими как Oracle. Я часто слышу утверждения, что они в N раз быстрее Oracle. Это хвастовство? В конце концов, Oracle — это эталонный продукт мирового класса, как он может быть в n раз быстрее?

Ну, не совсем.

В центре внимания Oracle не находится бизнес-анализ, который часто называют бизнесом AP. Он в основном используется для транзакций, которые часто называют бизнесом TP. База данных TP должна использовать хранилище строк. Базы данных AP обычно используют столбчатое хранилище. В таблице данных со 100 столбцами для операции необходимы только два столбца. Когда Oracle использует хранилище строк, ему, по сути, приходится читать все 100 столбцов. Однако базе данных AP, использующей хранилище столбцов, необходимо прочитать только 2 столбца, и объем чтения будет в десятки раз хуже. В настоящее время это нормально и неудивительно — быть в N раз быстрее. Если это не в N раз быстрее, это проблема. Помимо того, что хранилище столбцов лучше, чем хранилище строк, может также случиться, что кластер лучше, чем одна машина, память лучше, чем внешнее хранилище и т. д. Это означает, что он использует в несколько раз больше ресурсов, чем Oracle, и работает быстрее. Короче говоря, они все победили.

Поэтому так называемая N раз быстрее, чем Oracle, вероятно, означает это. Это не ложь, но этим не стоит хвастаться. Фактически, оптимизатор Oracle очень мощный, если он не использует преимущества столбцового хранилища и ресурсов, многие профессиональные базы данных AP не смогут превзойти Oracle, особенно те, которые основаны на технологии Hadoop.

Как уже говорилось ранее, мощность логарифмических алгоритмов, масштаб триллионов строк, количество вычислений после логарифма составляет всего несколько десятков. На самом деле бывает и обратная ситуация. Объем данных может показаться не большим, но объем вычислений будет астрономическим. На форуме SPL есть пример Национальной астрономической обсерватории. В данных всего 11 таблиц с 500 000 строк, а общий объем составляет менее 10 ГБ. Однако для вычислений в течение 3,8 часов использовалось 100 процессоров. Поскольку эта операция представляет собой уровень сложности умножения, общая сумма вычислений составляет 10 * 500 000 * 500 000 = 2,5 триллиона, и ее можно выполнить за 3,8 часа, что довольно хорошо.

Поэтому, изучая производительность продуктов больших данных, вы не можете просто смотреть на лозунги, в которых говорится, какой объем данных может обрабатываться и как быстро они могут работать. Эти утверждения могут быть верными, но они бессмысленны. С хорошим алгоритмом 100T можно проверить за секунды. Без хорошего алгоритма 10G все равно может занять N часов. В этом смысле ключом к изучению эффективности технологии больших данных является то, предоставляют ли она уникальные и хорошие алгоритмы, которые могут сократить объем вычислений.

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

Однако, выйдя за пределы системы SQL, можно придумать новые алгоритмы. Для упомянутой выше задачи обсерватории на самом деле существует алгоритм, который может уменьшить логарифм одной стороны умножения. Сумма расчета составляет примерно 10 * 500 000 * log500 000 * 2, которую можно уменьшить в 10 000 раз. Используя этот алгоритм, esProc SPL закончился за 2 минуты на 4-ядерном ноутбуке.

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