База данных для сверхбыстрого запроса

У нас есть массив данных размером 300 Гбит +, который мы хотели бы запросить как можно быстрее. Традиционные базы данных SQL (в частности, SQL Server) не могут обрабатывать этот том так эффективно, как нам нужно (например, выполнить select с условиями 10-20 в разделе where менее чем за 10 секунд), поэтому я исследую другие решения для этой проблемы.

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

Что вы можете предложить здесь?

ИЗМЕНИТЬ, чтобы уточнить, что нам нужно.

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

Когда пользователь входит в систему на сайте, ей представлена форма, аналогичная следующей:

alt text http://queenbee.alponline.ru/searchform.png

Здесь пользователь выбирает, куда она уходит и куда она идет, даты, продолжительность и все это.

После нажатия "Поиск" запрос отправляется на наш сервер БД, который, с такой обработкой не может обрабатывать: запросы включают различные параметры. Sharding тоже не работает.

Итак, что мне нужно, это псевдо-база данных, которая может делать молниеносные запросы.

Ответ 1

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

300 ГБ не должны выходить за рамки возможностей современных платформ RDBMS, даже MS SQL Server. Некоторые другие варианты для больших запросов к базе данных этого типа:

Посмотрите, можете ли вы использовать кубы и агрегаты SSAS для смягчения проблем с производительностью запросов. Оптимизация на основе использования может обеспечить вам адекватную производительность без необходимости использования другой системы баз данных. SSAS также может использоваться в конфигурациях без общего доступа, что позволяет вам разглашать ваши запросы через кластер относительно дешевых серверов с дисками с прямым подключением. Посмотрите на ProClarity для front-end, если вы все пойдете этим путем.
Sybase IQ - это платформа RDBMS, которая использует базовую структуру данных, оптимизированную для отчетности. Преимущество заключается в том, что он отлично работает с разумным набором стандартных средств отчетности. Существует несколько других систем такого типа, как Red Brick, Teradata или Greenplum (в которых используется модифицированная версия PostgreSQL). Основной удар по этим системам заключается в том, что они не являются точными массовыми рыночными позициями и могут быть довольно дорогими.
У Microsoft есть версия SQL Server, не имеющая ничего общего, в которой вы можете использовать. Однако они привязали его к сторонним производителям оборудования, поэтому вы можете получить его только с помощью специализированного (и, следовательно, дорогого) оборудования.
Посмотрите на возможности создания витрин данных с агрегированными данными для уменьшения объемов для некоторых запросов.
Посмотрите на настройку вашего оборудования. Прямое прикрепление массивов SAS и RAID-контроллеров могут быстро передавать потоковые операции ввода-вывода сортировки, используемые в табличных сканированиях. Если вы разбиваете свои таблицы на большое количество зеркальных пар, вы можете получить очень быструю производительность потоковой передачи - легко способную насыщать каналы SAS.

Практически вы смотрите на получение 10-20 ГБ/сек от вашего I/O, если вы хотите, чтобы целевые показатели производительности вы описали, и это действительно возможно сделать, не прибегая к действительно экзотическому оборудованию.

Ответ 2

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

Ответ 3

Правильно настроенный SQL-сервер должен иметь возможность обрабатывать данные в terrabytes без проблем с производительностью. У меня есть несколько друзей, которые управляют базами данных SQl Server, размер которых не имеет проблем с производительностью.

Ваша проблема может быть одной или несколькими из следующих:

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

Это, безусловно, НЕ является способностью SQL Server обрабатывать эти нагрузки. Если у вас есть такой размер данных, вам нужно нанять профессионального dba с опытом оптимизации больших систем.

Ответ 4

Я ожидаю, что "обычная" база данных сможет делать то, что вы хотите, если вы правильно структурируете свои данные для запросов, которые вы делаете.

Вы можете обнаружить, что для обеспечения достоверности отчетов вам необходимо суммировать свои данные по мере их создания (или загружать, преобразовывать и т.д.) и сообщать сводные данные.

Скорость SELECT не связана (в большинстве случаев, в большинстве случаев) с числом условий в предложении WHERE (обычно), но это связано с планом объяснения и количеством проверенных строк. Есть инструменты, которые будут анализировать это для вас.

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

IO ops являются королями:)

Очевидно, что делать это очень дорого с точки зрения времени разработчиков, поэтому вы должны начать с того, что бросаете много аппаратного обеспечения, и только пытайтесь исправить его с помощью программного обеспечения, когда это становится недостаточным. Много оперативной памяти - это старт (но он не сможет хранить > 10-20% ваших данных за один раз на текущих экономически эффективных уровнях). Даже SSD в наши дни не так дороги.

Ответ 5

Это действительно зависит от того, какие предложения вы имеете в своем ГДЕ и какой проекции вам нужны в ваших данных.

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

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

Ответ 6

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

См. колонка, ориентированная на СУБД, для более подробного объяснения, чем я мог бы дать

Ответ 7

NoSQL, как вы, возможно, читали, не является реляционной базой данных.

Это база данных, в которой хранятся пары ключ-значение, которые вы можете перемещать с использованием запатентованной API.

Это означает, что вам нужно будет определить физический макет данных самостоятельно, а также сделать любую оптимизацию кода.

Я довольно устарел от этого, но несколько лет назад я участвовал в проекте BerkeleyDB, касающемся чуть меньше, но все еще большие объемы данных (около 100Gb).

Это было прекрасно для наших нужд.

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

Ответ 8

Попробуйте Clickhouse получить результат теста, который быстрее в большинстве случаев даже из MemSQL, но вы не можете обновить запись, только вставить/удалить