Таким образом, SQL и NoSQL движутся навстречу друг другу, а со временем могут слиться в единый подход SQL+NoSQL к разработке СУБД. Возникает вопрос: что лучше использовать — NoSQL или SQL? Широко распространенная и хорошо изученная реляционная СУБД дает массу дополнительных преимуществ: интеграция с уже существующими решениями на базе реляционных СУБД, отказоустойчивость, наличие более богатого инструментария и т. д. Сейчас наблюдается тенденция применения NoSQL вместо SQL, но не исключено, что по мере развития SQL начнется обратное движение. Со временем, чем ближе будут становиться SQL и NoSQL, тем больше будет «метаний» от одного подхода к другому.
При объединении SQL и NoSQL в единое решение из-за многообразия используемых методов хранения информации СУБД может превратиться в огромный черный ящик со сложными и разветвленными настройками, что сильно затруднит работу с ней. Похожая ситуация уже происходила с некоторыми языками программирования (например, Алгол-68, PL/1), когда их семантика оказалась сильно перегружена и вместо удобного инструмента разработчики получили плохо управляемого «монстра». Кроме того, если будет разработан стандарт на системы SQL+NoSQL, то он может оказаться слишком сложным и перегруженным.
Решение заключается в корректировке самой концепции СУБД, подразумевающей, что такие системы должны представлять собой не монолитный сервер с комплектом инструментальных средств, а набор хорошо интегрируемых блоков, каждый из которых решает конкретную задачу обработки данных (например, кэширование, распределение нагрузки, компрессия данных, передача по сети и т. д.), не является самодостаточным и требует надстройки высокоуровневых модулей. Это позволит максимально учитывать специфику хранимых данных и обрабатываемых запросов.
Современные реляционные СУБД включают в себя все необходимые подсистемы управления данными (накопление, контроль целостности, кэширование, оптимизация и выполнение запросов, репликация и т. д.). После слияния SQL с NoSQL новые СУБД будут предоставлять только «низкоуровневые» модули работы с данными, а все остальное (например, распараллеливание сложных запросов или стратегия кэширования) программист должен либо настроить самостоятельно, либо использовать типовую конфигурацию. В результате для каждого применения будет создаваться целевая СУБД. Уже сейчас для многих практических задач (полнотекстовый поиск, хранение словарей) гораздо эффективнее реализовать собственное узкоспециализированное решение вместо использования СУБД.
NoSQL в работе
Все датчики из задачи предыдущей врезки дают показания раз в секунду, поэтому можно сделать следующее. Во-первых, вместо показаний времени использовать номер секунды, прошедшей с начала месяца. Во-вторых, использовать его не как ключ ассоциативного массива, а как индекс одномерного массива показаний датчика за месяц.
Каждый датчик изменяет свое значение плавно, и последовательность его показаний имеет смысл хранить по аналогии с инвертированными индексами в поисковых системах. Так, история показаний разбивается на дни, а для каждого дня хранится начальное показание датчика и последовательность дельт. В итоге за один день будет накапливаться 24 x 60 x 60 = 86 400 чисел, но 86 399 из них окажутся близки к нулю (так как датчик меняет значения плавно) и будут очень хорошо сжиматься. Если сжатие будет 10-кратным, то для хранения показаний одного датчика за один день понадобится 24 x 60 x 60 = 86 400 чисел, что потребует примерно 350 Мбайт без сжатия и 35 Мбайт со сжатием. Соответственно, вся база будет занимать около 10 Гбайт, при этом ее можно разбить на файлы, содержащие показания набора датчиков за некоторый промежуток времени. Это позволяет подобрать оптимальные параметры разбиения базы на файлы и добиться чтения информации в интерактивном режиме.
Для ускорения скорости анализа нужно хранить дополнительную битовую матрицу, строки которой соответствуют датчикам, а столбцы — моментам времени. Элемент матрицы равен 1, если в данный момент времени данный датчик меняет свое значение больше чем на указанную фиксированную пороговую величину. Суммарно вся матрица будет состоять из 2 592 000 x 10 000 ячеек, что потребует 3 Гбайт памяти, но поскольку датчики меняют свое значение плавно и редко, то матрица будет сильно разреженной и при сжатии займет не более 300 Мбайт.
При представлении в памяти битовую матрицу можно развернуть по строкам или по столбцам. В первом случае матрица распадется на набор битовых векторов, каждый из которых соответствует одному датчику, а его отдельные биты — моментам времени. Для определения того, изменяют ли свое значение два датчика одновременно, необходимо выполнить операцию побитового «И» соответствующих им векторов. Во втором случае матрица распадется на набор битовых векторов, каждый из которых соответствует одному моменту времени, а отдельные биты — датчикам. При таком способе хранения очень эффективно реализуется алгоритм Apriory для поиска датчиков, одновременно меняющих свое значение. Оба рассмотренных подхода имеют свои преимущества, но ничто не мешает хранить в памяти оба представления матрицы. Также ничто не мешает завести аналогичные матрицы для исследования других признаков.
С точки зрения реализации будет рациональным разделить битовые матрицы на блоки (один блок соответствует набору датчиков и некоторому промежутку времени), хранить их в памяти и не производить операции ввода/вывода. Тогда скорость работы данной целевой СУБД будет зависеть только от быстродействия процессора. Поскольку нужные для этого алгоритмы хорошо распараллеливаются, то возможно добиться работы системы в интерактивном режиме.
Вместе с тем данный пример наглядно демонстрирует, что указанную задачу пока неспособны эффективно решить и существующие NoSQL СУБД —эта технология находится еще на этапе становления, и ей еще предстоит проделать долгий путь до того, как стать промышленным стандартом, подходящим для решения широкого круга практических задач. Однако концепция целевых СУБД хотя и покрывает рассмотренное решение, но находится в еще более зачаточном состоянии.
Примечательно, что оптимизаторов запросов в новых СУБД вообще не требуется, так как количество типов подаваемых системе запросов известно заранее и программист сможет самостоятельно указать все особенности оптимального выполнения каждого из них. Поскольку система ориентирована на работу с большими объемами информации, то во время ее эксплуатации вряд ли стоит ожидать значительного изменения статистических закономерностей в базе, и, следовательно, вряд ли придется корректировать оптимальный план выполнения запроса. Вместо планировщиков запросов будут востребованы различные средства мониторинга разрабатываемой или уже используемой системы — цель их работы состоит в нахождении «узких» мест и выработке рекомендаций по улучшению системы.
Логическим завершением подхода построения целевых СУБД вместо использования классических серверных архитектур является движение в сторону RAD (Rapid Application Development), при котором программист формально описывает качественные и количественные требования к создаваемой СУБД, получает предварительное решение, а затем оптимизирует его отдельные элементы вплоть до самостоятельной реализации отдельных блоков. Созданная таким образом целевая СУБД может быть впоследствии развернута на любой инфраструктуре, включая и облака.
По принципу создания и применения целевые СУБД чем-то напоминают инструменты ETL для загрузки данных в информационные хранилища. Сейчас эти инструменты не готовы для вызова из программ, но позволяют создать, отладить, оптимизировать и многократно использовать саму процедуру ETL. Примерно по той же схеме работают генераторы запросов, и примерно по той же схеме могут работать СУБД типа SQL+NoSQL.
***
Два направления развития СУБД — SQL и NoSQL — во многом противопоставляются, хотя и подчиняются единым законам и движутся навстречу друг другу. Пока это движение почти незаметно, но оно активизируется по мере появления необходимости в средствах построения высоконагруженных систем, в результате чего произойдет слияние этих направлений. Получившиеся таким образом СУБД могут оказаться слишком громоздкими для использования на практике, поэтому, возможно, произойдет отказ от текущей архитектурной концепции СУБД в сторону появления СУБД, представляющих собой набор «кубиков» для построения целевой системы, обладающей характеристиками, необходимыми для конкретных высоконагруженных приложений.