Второе дыхание SQL. Техническое эссе.

Дальние перспективы развития баз данных. Disclaimer : я не читаю литературу посвязенную далеким прогнозам. Пока хватает того что будет через год или два. Поэтому мозг у меня чист как белый лист и не affected чужими прогнозами. Так что если кто данной темой интересовался, интересно будет сравнить

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

То и дело возникают возгалсы – ура ! пришли OODB. Увы, это направление дискредетировало даже имя OODB, так что теперь предпочитают говорить о post-relational db.

Или ура – придет Yukon и можно будет забить на SQL и писать на C#. Еще один миф. Ну кое кто так и сделает… и даст много работы DBA, которые потом это будут заставлять работать с нормальной скоростью. Но OODB – это отдельная большая тема

Мысль же автора здесь – SQL не только не исчерпал свой потенциал, но скоро переживет свое второе рождение. Попытаюсь обосновать

Давным давно, когда я еще учился в знаменитой 30 школе, преподаватель программирования со смешной фамилией Мелведь (а был еще и Карп. Ему вырезали и принесли статью с заголовком ‘карп просится на сковородку’ ) заявил : Никогда не будет процессоров делающих более миллиарда тактов в секунду !

Время показало что он не прав. Но не прав в цифре, но не в принципе. Действительно, законы природы не дадут сделать процессор быстрее 10Ghz. А к этой величине мы идем слишком быстро, и я думаю многие помнят как клавиша Turbo переключала на экранчике частоту 6 и 12 Мhz.

Мы упремся в этот тупик около 2006-2007гг

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

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

Конечно ! SQL ! Старый добрый SQL является языком со скрытой массивной паралелльностью. Уже сейчас оптимизаторы генерят параллельные планы. Все что потребуется – это правильный генератор плана выполнения. Как протокол IP из преданий старины глубокой пришел в наши дни, пережив несколько поколений технологий, так и SQL, как ни странно, окажется die hard нового века.

Итак, процессоров становится все больше и больше. В пределе на каждую запись приходится один процессор. И когда мы говорим update TAB set n=n+1 where COND, все процессоры получают одну и ту же каманду, независимо проверяют условие COND, и быстро производят изменение.

Цена Table scan становится равной одному абстрактному такту базы, а индексы становятся не нужны (искать нужный процессор не быстрее чем отослать команду всем).

В реальности конечно каждый процессор будет зранить много записей. Сколько ? База 1T при 32768 процессорах делится в размере 30M/процессор. А значит, процессор может все держать в памяти ! А как потеря питания ? Очевидно, у него должна быть батарейка, чтобы успеть сбросить это 30M, точнее, модифицированную часть, в свою энергонезависимую память.

Итак, мы получили database cell в виде процессора, маленькой специализорованной OS, быстрой памяти и памяти энергонезависимой. Сама система набирается из тысяч таких ячеек. Мы увидим (2009-2010г) базу данных в виде аппаратного комплекса. Предком таких систем являются сейчас disk arrays, которые постепенно ‘умнеют’

Само условие поиска может быть довольно сложным. Так как индексов нет, то мы просто можем проверить его в лоб. Вот и пришел конец full text search… Скорее всего поиск будет вестить не в plain rows, а в XML (тотлько плотно упакованных) документах.

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

Вот просто некоторые мысли.

Комментарии

2010 год, скоро 2011

2010 год, скоро 2011 а SQL живее всех живых. Предсказание про аппартаные СУБД пока не подтвердилось, но все-таки проблема как программировать под многопроцессорные/многоядерные системы уже стучится к нам в двери. И практически как результат - возрождение интереса к языкам функционального программирования как возможной декларативной панацее. Т.е. все ищут как ФП может стать в обычном программировании тем-же что и SQL в системах управления данными.

Изображение пользователя ipanshin.

Кто хоронил sql,

Кто хоронил sql, тот сейчас говорит о его втором рождении. Я его никогда не хоронил, а поработав в docsvision, утверждаю, что проблема скорее всего лежит в психологическом невосприятии многими сильными программистами технологии или терминологиии SQL. Поэтому этот слой очень глубоко закопан в проектах и обернут в штанишки SQL кодогенераторов. Кстати и у 1С8 таже самая петрушка. Да собственно говоря у всех современных систем наблюдается этакая sql боязнь или sqlфобия. Нет, чтобы повернуться к sql лицом и сказать: "Я буду писать обработчики событий только на sql". И мгновенно мы получаем а-ля nexus, который в смысле многопроцессорных систем уже полностью готов к параллельному выполнению.

Собственно, параллелизм SQL предложений был ясен и известен еще в 80 годах. Правда, не стоит забывать, что у параллелелизма существует закадычный друг поточный конвейер (pipeline). То есть здесь идет усложнение среды передачи данных. Например, вместо простых проводов ставятся провода, реализующие, скажем рекуррентный алгоритм решения систем с дробно-рациональной функцией на основе МНК.
Зачем отдельно стоящий процессор, если можно усложнить провода передачи?

database cells. И кто же ими всеми будет управлять? Единый мировой центр?

А чего углублять? Надо подреда

А чего углублять? Надо подредактировать и выложить as is.
А углубим мы уже в рамках полемики.

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

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

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

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

Нынешний подход опять идет от статистики, а это значит что SQL будет продолжать развиваться, как самый эффективный инструмент хранения и обработки больших массивов данных.
Развиваться он будет по 2-м направлениям - увеличение мощности (объем, быстродействие, снижение отношения "фактический объем/полезный объем") и развитие фукциональности, для удовлетворения потребностей в более сложной обработке данных.

Не думаю, что решение будет подобно описываемому DT, т.к. современные параллельные архитектуры эффективно работают в диапазоне 4-8 процессоров. Дальнейшие увеличение кол-ва процессоров не приводит к заметному повышение быстродействия всей системы.
(Примечание: не надо сразу пинать, я прекрасно знаю, что есть системы с сотнями процессоров, но они как правила работают под очень специальным софтом и для очень специальных задач - моделирование процессов физики ядра. Для таких задач даже 1% вычислительных мощностей может означать экономию нескольких часов или дней).

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

Изображение пользователя st.

Хотелось бы обощить, что потен

Хотелось бы обощить, что потенциальной способностью к параллельному исполнению имеет любой декларативный язык, одним из которых является SQL.
Декларативные языки требуют больших аппартных ресурсов для исполнения. Эти ресурсы появляются в последние годы.
Сейчас, например, растет интерсе к функциональным языкам.
Prolog опередил свое время лет на 20. Мы еще к этому вернемся.
Прорыв же случится, когда декларации можно будет задавать на естественном языке.

2SBОграничение 4-8 процессор

2SB
Ограничение 4-8 процессоров это для архитектуре SMP
Больше не получается изза конфликтов по памяти
Масивнопараллельные струкруты тем и отличаются что у них у каждого процессора память своя
Поэтому и ограничений нет

Про выбор данных все понятно.

Про выбор данных все понятно.

А вот скажите, как в такой архитектуре будет организовано дополнение данных.

Я сейчас использую сегментированные таблицы в Oracle, там это организованно по диапазону некоторого набора полей. Самый триввиальный случай - это дипазон дат.

Как будет вычисляться какому процессору дать запрос на insert?

Про выбор данных в

Про выбор данных все понятно.

А вот скажите, как в такой архитектуре будет организовано дополнение данных.

Я сейчас использую сегментированные таблицы в Oracle, там это организованно по диапазону некоторого набора полей. Самый триввиальный случай - это дипазон дат.

Как будет вычисляться какому процессору дать запрос на insert?

Команда вставки ьулет передана всем процессорам
Тот кто ответственен за данный даипазон вставит
Остальные проигнорируют

Команда вставки ьу

Команда вставки ьулет передана всем процессорам
Тот кто ответственен за данный даипазон вставит
Остальные проигнорируют

А если все проигнорируют? Допустим значение не входит ни в один из диапазонов.
Oracle в этом случае ни чего не делает, т.е. данные теряются.

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

Все транзакции по определнию будут распределенными, с 2-х фазным коммитом.

Программно аппаратный комплекс будет настроен на конктретную БД, что внесет ощутимую сложность в востановлении backup на другом сервере. У меня было, мягко говоря, большое изумление, когда я узнал, что backup БД Oracle из Linux не может быть восстановлена под NT.

Изображение пользователя st.

При этом возникает т.н. пробле

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

Изображение пользователя ipanshin.

Что-то случилось? :) Архит

Что-то случилось? :)
Архитектура MIMD была известна в прошлом веке. Но это не значит, что надо сводить архитектуру СИСТЕМЫ к муравейнику. Развитие будет в одном направлении - это мозг, вначале ограниченный и специализированный, в конце всемирный и универсальный. Так что бросьте все, что уводит от идеи централизованного управления иначе, конечно не умрете, но окажетесь далеко на периферии, например, в области кобчика. Там много работы и там будут работать программы С++.
Prolog,Pagen and SQL ... Безсмысленно выбирать что-либо априори. Использовать только по месту. Но СКРИПТ - ПЕРВИЧЕН. Ибо сначало было слово и дух летал над бездной. А потом уже всяка ерунда, что храним в БиДэ.
Заметьте я не рассматриваю nexus как нечто отдельное, но только в совокупности с SQL. Потому что SQL - это СКРИПТ. А NEXUS - это нефункциональный клиент, то есть он ничего не делает своего, кроме центрального SQL скрипта. Цена владения практически нулевая по отношению к возможностям.
И это хорошо.