Comments 105
А у нас все иначе, озарений не было, был исторический процесс, войны моделей и стандартов, война инженерии с маркетингом, и окончательная победа маркетинга и виртуализации реальности.
Тот редкий момент, когда пропустив половину истории получается не укорочённая версия, а совсем другая история и другие выводы.
Особенно доставило, что про джойны(которые в случае острой необходимости довольно прямо лепятся поверх любого kv-хранилища) есть, а про распределенные транзакции, в которые все реляционки очень бодро упираются — нет.
Кстати, и мое ощущение от обратного движения в сторону реляционных бд вовсе не в том, что они прям сильно лучше стали, а в том, что хайпа про «моему уютному бложику не прожить без шардирования и репликации» поубавилось. Ну и виртуализация стоит теперь дешевле чашки кофе и расти вертикально теперь сильно проще и дешевле.
Из реальной практики, была задача год назад, где надо хорошую однопоточную производительность на серверном железе обеспечить. Взяли e5-2643v4 (3.4 GHz частота, максимум, что есть на рынке). На домашних дешевых процессорах куда веселее цифры, увы.
Потому что инстанс с терабайтом озу стоит семь баксов в час?
Есть ощущение, что это очень сильно уменьшает потребность в горизонтальном масштабировании.
А зачем вы упираетесь в тактовую частоту?
Я вот сравнивал core i7-2600 6-летней давности и порезанный core i5-2.0 из макбука — они по производительности на ядро идут нога-в-ногу уже (отличаясь по тестам ровно в два раза по multi-core, что соответствует разнице в количестве ядер). При этом i5 в 10 (десять!) раз энергоэффективнее.
— Java + MongoDb = просто добавить три строки кода(депенденси), все работает и устойчиво
"Narrow waist" не надо переводить как "узкое место". "Узкое место" в техническом сленге носит ярко выраженный негативный оттенок, ближайший аналог в английском это "bottleneck". Узкое место — это плохо, его надо или ликвидировать, или обойти.
Автор же имел ввиду скорее позитивное явление, что IP выступает как общее связующее звено для разнообразнейших транспортно-прикладных протоколов и способов организации передачи данных. Это просто закономерный исторический факт, как и то, что все программисты говорят друг с другом на английском.
Забавно, что как сетевики пытаются съехать с IPv4 на IPv6, так и программисты тяготеют к созданию локальных коммьюнити. Выглядит так, будто "narrow waist" это вынужденная мера, от которой при необходимости попытаются избавиться.
Надо ли адаптировать SQL как "narrow waist" в данных, когда там и так справляются многообразием технологий и языков? Получается, вопрос весьма дискуссионный.
там все реально по другому. суть иерархической субд — нафигация по индексу, суть того о чем я говорю противоположна. там зачастую читают абсолютно все данные начала времен.
не совсем так. Каноничный пример иерархической БД — это файловая система.
В ней можно легко создать папку для пользователя и в неё положить все его просмотренные сайты.
Документные СУБД всё же отдельный класс с ограничением на размер документа. т.е. нельзя будет всю историю одного человека запихать в один документ.
После длительного увлечения NoSQL, я начинаю задумываться о том же. Колоночные NoSQL со всей их спецификой (гиганские объемы данных, данные очень регулярны, потери отдельных строк не важны) имеют права на жизнь, но для всего остального проще использовать SQL
- современные SQL базы не медленны — постгрес на слабой машине тянет тысячи запросов по денормализованной таблице в секунду
- с большим кол-вом данных проблем тоже нет
- в 21 веке не нужно уродовать структуру и индексы для аналитических запросов — данные просто экспортируются в любимую колоночную СУБД или индексатор
- шардинг средствами современных технологий легко реализуется на стороне клиента
- с availability сложнее, но значительно проще, чем раньше
И помимо этого, SQL базы дают транзакции, мощный язык запросов, качественные атомарные бэкапы, проверенный временем мониторинг, аудит и средства восстановления после аварий.
Для SQL РСУБД само собой подразумевается наличие ACID. С этим у NoSQL все очень плохо, поддержку ACID заявляют только мифический Google Spanner, глюкавый OrientDB и ныне почивший FoundationDB. Языковая обертка совсем не спасает — SQL в NoSQL используют почти исключительно для OLAP.
В другую сторону, для NoSQL часто подразумевается почти линейная масштабируемость и shared-nothing. С этим у классических РСУБД все очень плохо — транзакционный движок это нерасширяемый SPOF, мастер-мастер репликация это безнадежно, универсальное шардирование не совместимо с контролем строгости внешних ключей и т.п.
Для SQL РСУБД само собой подразумевается наличие ACID.
Спорное утверждение. В общем, конечно, как бы да, но строго говоря не обязательно, ACID — это всего лишь фича, которая может быть, а может отсутствовать. Сам, например, прекрасно живу с энджином Aria (улучшенный MyISAM) в некоторых bigdata (но не hiload) проектах с MariaDB — вполне себе классический SQL, но без ACID и шурует достаточно быстро по сравнению с InnoDB на больших таблицах.
А вообще ваши доводы, конечно, ясны, всё так, да.
На заре хайпа про NoSQL у этой аббревиатуры было еще одно значение — Not Only SQL. Что идеологически гораздо более правильно, но вот только про хорошие примеры SQL + что-то ещё в одном флаконе мне неизвестно.
NoSQL-база — это база со скромным индексированием (индексируется только первичный ключ)
Для документных СУБД это неверно, можно навесить любые индексы, если это требуется.
Так о чем же в итоге статья — о языке запросов SQL или о реляционной модели хранения данных, в которой этот язык применяется. Spanner, к примеру, не реляционка, но при этом использует SQL.
А мы вот, например в своей NoSql СУБД используем модифицированные XQuery и XUpdate, и очень довольны. Запросы проще и выразительней чем SQL на порядки. Пользователи легко осваивают язык за пару недель. Прикручивали SQL, но разработчики не приняли после XQuery, не стали развиваить.
Наверное, стоит разделить слой хранения данных и слой DML.
В Oracle, строго говоря, данные хранятся не в плоской таблице, а в дереве, но это не делает его NoSQL СУБД. Слой хранения может быть разным — может быть на одном узле как в MySQL, может быть на распределенном block storage, как в Aurora, может быть размазан по многим узлам, как в CockroachDB или Spanner. Значение имеет всё же интерфейс взаимодействия.
И реляционная модель ни слова не говорит про хранение — это логическая модель данных, не физическая, которая просто утверждает, мы можем оперировать с данными как с множествами кортежей, и можем пользоваться булевой алгеброй для задания предиката, применение которого вернет множество нужных элементов.
Запросы проще и выразительней чем SQL на порядки
модифицированный XQuery
а можно пример, пожалуйста? Интересно стало.
Просто всегда думал, что XML — это не тот язык, который могут писать живые люди.
SQL увы часто слишком высокоуровневый и трудный для оптимизации язык.
Он никак не описывает взаимодействие с индексами или какой алгоритм джойна или выборки использовать. В общих случаях и небольших нагрузках всё может быть хорошо, но дальше начинаются танцы с бубном над оптимизатором. Да и для многих случаев разбор и оптимизация занимает больше времени чем сама выборка данных.
Ну и сам по себе SQL не очень знаком с транзакциями и изоляциями.
Всё есть, пусть и специфичное для базы. Хинты, select for update, WITH ROWLOCK и т.п.
Вот здесь я склонен немного не согласиться, потому что
или часто правильно написанный +0 при джойне в Firebird,
или грамотно подсунутый хинт индекса в MySQL,
или грамотно построенный индекс для MS SQL,
или грамотно переписанный запрос с использованием фишечек (оконные функции, CTE) в PostgreSQL,
или переписывание запроса на (о ужас :-) ) хранимую процедуру PL/SQL с простой линейной логикой (привет, Oracle),
способны исправить любую глупость оптимизатора.
И это всё тоже остаётся в рамках SQL (за исключениме хранимых процедур разве что).
Проблема в другом — эти решения применимы только для конкретного движка СУБД, т.е. имеем примерно такую же фигню как с NoSQL — для эффективной работы с каждым хранилищем данных приходится как-то по-особенному приседать — писать запросы, продумывать структуру таблиц, что развеивает миф о возможности существования всемогущего, одинакового для всех БД, языке.
Ну вот хотелось бы стандартизированного инструмента (языка) для существующих СУБД.
Ведь сделали же webassembly для веба и SPIRV для шейдеров, почему бы не сделать SQL Asembler? Некое промежуточное представление, которое было бы немного ниже текущего SQL но всё ещё сохраняло бы переносимость.
Прошу меня извинить, но уровни изоляции — это то, что выбито гвоздями в SQL-92. Это стандарт.
Его в том или ином виде полностью поддерживают почти все движки. Да, немножко со своими странностями, но тем не менее. Если СУБД не поддерживает уровни изоляции и транзакции, то это какое-то недоразумение, а не полноценная СУБД. SQLite в расчет не берем — это встраиваемая записная книжка с SQL-синтаксисом.
Я скорее про реализацию, толку от языка, который если хочется чего то предсказуемого по скорости, приходится писать под каждую СУБД свой запросс?
Даже тут https://ru.wikipedia.org/wiki/%D0%A3%D1%80%D0%BE%D0%B2%D0%B5%D0%BD%D1%8C_%D0%B8%D0%B7%D0%BE%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8_%D1%82%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D0%B9 немного написанно про то что в мало каких СУБД это уровни реализованны строго по стандарту…
Есть же вроде устойчивое мнение что Read committed в Postgres это Repeatable read в Oracle.
И вы зря про SQLite это очень мощная СУБД и наглядный пример как можно использовать язык SQL (особенно их "компидятор" запроссов). И по колличеству инсталяций + работающего софта это наверная самая популярная СУБД в мире.
Конечно, посчитать все андроид-девайсы — будет самой популярной :-)
Я скорее к тому, что в SQLite нет как таковой необходимости иметь уровни изоляции — это по дизайну встраиваемая БД для локального применения в рамках одного процесса.
Там нет и хранимых процедур, и многопользовательского доступа по примерно тем же причинам. Это просто библиотека (не СУБД) с SQL-like синтаксисом. Очень полезная в хозяйстве, надо сказать. Отдельно хочется похвалить автора за его любовь к автотестам.
Если я правильно помню, то хранимок нету и в MySQL/MariaDB и это никакого отношения к SQL не имеет. А так наверное да, но это всёравно применение SQL языка.
в MySQL и MariaDB есть хранимые процедуры.
Кривые, косые, но есть. Тоже не от хорошей жизни они там появились =)
Я имел ввиду, что SQLite нельзя назвать "взрослой" клиент-серверной СУБД, которая умеет работать с большим объёмом данных и большим числом одновременных клиентов.
Кстати, это не очень связано с невозможностью работать с большими данными. Размер данных зависит от возможностей файловой системы.
По первому абзацу целиком и полностью согласен.
Кстати, это не очень связано с невозможностью работать с большими данными. Размер данных зависит от возможностей файловой системы.
Что есть большие данные? Я раньше слышал определение — они не влазят в ни в один из доступных на массовом рынке серверов. И там далеко не только в файловой системе возникают проблемы.
Накинулись на NoSQL но чуда, как обычно, не произошло и все стало на свои места.
Собственно если так подумать, то главная претензия к самому языку это отсуствие вменяемого синтаксиса (точно не как в новом стандарте) для доступа к сложным иерархиям внутри одного поля (документа). Если бы это было, то и Эластиксёрч с Монгой можно было бы перевести на этот язык.
ЗЫ хотя если так подумать, к примеру вложенные группировки в Эластике явно выглядят приятнее чем нагромождение которое будет в SQL.
Это я поро применимость SQL в документо ориентированных БД.
Кеширование, сообщения в соцсетях и месенжерах и т.д. Собственно и есть ниша NoSQl.
SQL остаётся хорошим для статической модели данных. Там же где данные ненормализованные, либо очевидно, что модель будет и должна меняться, он излишне строгий.
Так что не-SQL пока ничто не грозит, как никогда и не грозило.
например в класическом доступе по индексу.
Как минимум они делают разные вещи внутри этого доступа. Собственно prepare statement не от хорошей жизни появился так что SQL имеет существенный оверхед особенно если в нём перечисленно много "таблиц".
Тем неменее, большинство NoSQL на порядок (SiC!!!) быстрее, чем SQL при решении 90% наиболее распространенных задач. Если быть точнее, то если в приложении нет оператора altertable, имеет смысл подумать — а какого тут делает SQL? Реально вопрос только в затратах на разработку — на SQL дешевле и к программисту требования на уровне плинтуса.
Движок любой базы данных работает не с реляционной алгеброй, а с аддами-делитами, гетами-путами, установкой в позицию ключа и некстами-превисами (т.н. курсоры). Это элементарные операции над базами данных «ключ-значение». А как вы эти пары в своем кластере устроите, и какие модели хранения этих пар выберете, зависит либо напрямую от программиста, либо от того слоя, который лежит между уровнем SQL и движком. Пока этот самый уровень проигрывает по производительности результата живому программисту в конкретных приложениях не просто вчистую, а с кратным отрывом. И сближения не видно.
Сравнение [SQL vs. non-SQL] это как бы аналог сравнения [C vs. assembler] с той разницей, что слой автоматической трансляции [C --> assembler] реализован, не побоюсь этого слова, почти совершенным образом, а слой автоматической трансляции [SQL --> non-SQL] — как иногда говорят, представляет собой «наивную реализацию».
Если объем небольшой, а запросов много, проблема появляется. Но это не самый типичный случай.
У меня к SQL есть пара претензий.
Сложность отладки и тестирования. Каждое условие в запросе — это по сути if, который создает минимум две ветки, которые нужно протестировать.
Т.е. даже на честную отладку самого обычного запроса нужно проверить минимум 2^(n+k) инвариантов, где n — это количество сравнений полей, а k — это количество входных параметров запроса.
Поведение с NULL. Мне конечно все говорят, что это норма, такова жизнь и вотэтовсё, но чёрт подери, это ещё сильнее ухудшает (1), делая мне 3^(n+k), и при этом всё начинает очень весело стрелять в рантайме, вываливая этот NULL, то туда, то сюда, когда кто-то внезапно сменит
inner joinнаleft join, просто потому что так стало надо.
- Протекающие абстракции слоя хранения и оптимизатора запросов.
Знание SQL не освобождает от ответственности написания эффективных запросов. В каждом движке есть свои заморочки, как данные эффективно запрашивать и для того, чтобы работать действительно грамотно, надо точить запрос под каждый движок отдельно.
На рынке работодателю не слишком интересно знаешь ты SQL или нет, куда важнее, работал ли ты с конкретной СУБД. Неофиты в каком-то движке имеют привычку писать совершенно по-другому и поливать тоннами ругани СУБД, когда она ведёт себя неожиданным образом, и это будет продолжаться, пока человек не разберётся, как СУБД данные хранит и как работают планировщик/оптимизатор/исполнитель запроса. Увы, не существует единого стандарта SQL, который будет абсолютно одинаково эффективно работать на всех рантаймах. И никогда не будет существовать, потому что есть требования обратной совместимости. // никогда не прощу ораклу, что у них NULL и пустая строка — это одно и тоже.
В случае, когда я делаю закат солнца вручную (пишу джойны, аггрегации, подзапросы прямо в коде приложения, делаю руками выборку, вотэтовсё), я могу это легко контролировать — сделать декомпозицию на несколько простых, часто чистых, функций, каждую из которых обложить тестами и комбинировать уже готовые абстрагированные блоки, контролируя таким образом сложность, как алгоритмическую, так и тестирования.
// опустим сложный вопрос эффективности работы со слоем хранения.
В случае с SQL запросы быстро разрастаются сами собой из-за кажущейся простоты и необходимости быстро напилить фичу. Они выглядят компактно и создаётся иллюзия, что ты точно знаешь, как он работает и что вернёт. На самом деле это не так.
В случае, когда я делаю закат солнца вручную (пишу джойны, аггрегации, подзапросы прямо в коде приложения, делаю руками выборку, вотэтовсё), я могу это легко контролировать — сделать декомпозицию на несколько простых, часто чистых, функций, каждую из которых обложить тестами и комбинировать уже готовые абстрагированные блоки, контролируя таким образом сложность, как алгоритмическую, так и тестирования.
в 80х годах прошлого века от этого подхода отказались в пользу cost based optimizator. это то же самое, что в сезон отпусков проложить маршрут через центр города, а потом весь год терять 3 часа в пробках, которые более сообразительная молодежь объезжает, потому что маршрут выбирает в зависимости от дорожных условий.
самое главное преимущество SQL — он не указывает как достать данные. это декларативный язык.
cost based optimizator
После чего результат стал крайне нестабильным т.к. зависит от собранной статистики и её качества. А что происходит если вам нужно много Join это вообще кромешный адъ. Собственно коррелацию между таблицами вообще может быть не получится эффективно сделать так как это слишком много доп. информации хранить надо.
Потом пришли разработчики и потребовали хранимых процедур и писали по сути императивный код, чтобы БД периодически не выдавала "Ну у вас и запросы" и не зависала наглухо.
Потом пришёл веб, и юзеров стало так много, что один сервер БД стал загибаться и логика поехала в приложение, где разработчики по сути закатывали солнце вручную.
Потом пришли разработчики и потребовали ORM, потому что SQL — это слишком сложно и продолжили закатывать солнце вручную на толстых аппликейшн серверах, используя БД просто как тупую хранилку данных.
А потом дырявая абстракция cost based оптимизатора начала протекать и через ORM.
А потом...
SQL не очень хорош, и я бы его ставил в ряд с каким-нибудь JS по причинам появления багов, но лучше пока не сделали. Так и живём.
На нынешнем проекте у меня оракл и хранимые процедуры, потому что нельзя просто так и взять и правильно написать запрос, который сделает то, что надо и как надо. Если писать то, что нам надо чистыми запросами, оптимизатор встаёт в позу и начинает выдавать совершенно наркоманские планы. И статистика тут ни при чём. А много простых запросов — это лишние раундтрипы между сервером приложений и БД, лишние заморочки с транзакционностью и код в аппсервере начинает выглядеть ужасно.
SQL побеждает, потому что немалое значение имеет также скорость реализации.
Отчасти потому взлетели далеко не лучшие языки программирования вроде PHP и JS — на них просто накидать поделку, которая будет хоть как-то работать.
SQL-запрос, делающий нужное, в среднем легко накидать. Непросто его поддерживать, изменять и сделать эффективным.
И в спарке побеждает SQL вовсе не потому, что нельзя оптимизировать запросы лучше автомата, просто так намного быстрее написать хоть какой-то работающий код. А руками оптимизировать, если автоматика с ума сходить начинает, можно и потом, когда деньги будут.
Так что да, автоматические планировщики и оптимизаторы лучше. Но не потому что они работают быстрее, чем написанный и отлаженный вручную код, а потому что они сильно ускоряют начальную разработку.
Не было бы нормальных людей, шарящих в СУБД, мы бы за хранимые процедуры даже не стали бы браться. Писали бы всё на аппсервере. Другое дело, что с большинство ораклом раньше не работали.
Есть у нас хороший ораклист. Целый один. Но скорость развития проекта просто не та, при которой он бы успевал что-то сделать.
И ещё живых ораклистов за вменяемые деньги найти — это огромная проблема.
И нет, нельзя написать запрос так, чтобы он был одновременно читабельным, поддерживаемым и при этом всегда делал что надо, в условиях, когда нужно регулярно менять что-то в схеме, добавлять/убирать возврат каких-то полей, когда поля скачут из not null в nullable итд.
Обычные запросы в таких условиях очень быстро превращается в убористую кашу с десятком джойнов и вложенных запросов, которая завешивает и оптимизатор, и ораклиста.
Тупые хранимые процедуры с последовательной логикой работают просто чудесно на этом фоне. И никаких вопросов с транзакционностью.
что касается ваших проблем, то у вас явно не доработал архитек, раз схема постоянно меняется. в рсубд принято воротить универсальные структуры, на все случаи жизни и на века.
Это не недоработка архитекта. Это жизнь такая — требования к системе меняются по мере её работы в продакшене, по мере уменьшения бардака на предприятии заказчика в уже автоматизированных областях и внесения под автоматизированный контроль нового бардака.
Архитект не всевидящее око — он не может предусмотреть всего.
Думаю, следует заметить, что у разных ERP разные возможности и, соответственно, разные схемы хранения.
Также следует заметить, что всё не укладывающееся в стандартную схему как правило дописывается сбоку внедренцами, в той или иной степени костылями, за исключением случаев, когда это не реализуемо на данной платформе в принципе.
Увы, не всё можно загнать под общую готовую схему.
Иначе заказчик уже купил и внедрял бы готовое решение.
Иначе бы всё ПО уже давно бы написали.
я и не утверждаю, что схема ломается постоянно.
На одной итерации добавилось поле, на другой стало not null, на третьей потребовалось поменять логику взаимодействия этого поля с другими, на четвертой — материализовать значение/агрегат в другую таблицу.
Просто такие изменения потихоньку наслаиваются друг на друга и потом становится очевидно, что мы из существующего решения уже выросли и время немножко поменять нормализацию в отдельных кусочках итд.
Неприятность заключается в том, что при рефакторинге надо очень хорошо тестировать, а SQL штука сильно завязанная на данные и требует большое количество тестов, если хочется надёжности.
— оно стоит того
А теперь новая вводная — требуется импортозамещение на Postgresql. =)
Глупости, можно конечно.
А теперь добавляем корректировки старых требований, вносим новые требования и получаем регулярную необходимость пересматривать и менять этот код. И приходим к проблеме экспоненциального роста инвариантов, которые необходимо протестировать, с ростом сложности запроса, о которой я упоминал выше.
Хранимые процедуры оказываются более удачным решением, т.к. их легко разбивать на блоки, тестировать, читать и писать.
Если слова «десяток джойнов» смущают ораклиста то его надо заменить, этот негодный
Десяток джойнов куда больше смущают оракловый оптимизатор, у которого случается горе от ума. И помимо ораклиста есть ещё другие члены команды, которые пишут и читают SQL, так что не поможет. Уж лучше аккуратненько писать ХП и потом их бить на кусочки, да оптимизировать помаленьку.
Оракл и постгрес прекрасно справляется с сотнями джойнов, он для этого и предназначен.
Кем и как это проверено? Это сильно зависит от структуры таблиц, данных, статистики, индексов, объёма данных.
Вы не справляетесь.
Справляемся, достаточно хорошо справляемся. И оракловый оптимизатор, в среднем по больнице, справляется, но в любом деле есть нюансы, упомянутые выше.
мы не умеем в скл
Мой пойнт в том, что не существует единого SQL, который всегда одинаково хорошо работает на любой СУБД. В каждом движке есть грабли и тонкости, из-за которых часто приходится делать иначе, чем в другой СУБД. Запрос, который идеально работает в pgsql, может быть неэффективным в oracle или в принципе не реализуемым (привет, пагинация в oracle 11, боже, как я ржал, когда увидел правильное решение). И это нормально.
выбрасываем деньги на оракл
Не мы выбрасываем, это было требование заказчика — использовать оракл, потому что у него уже готовая инфраструктура, админы, итд.
но пользуем иерархическую бд 30-летней давности
??? не понял, откуда такой вывод.
P.S. а можно без ad hominem и апломба? раздражает же и убивает адекватную дискуссию.
самое главное преимущество SQL — он не указывает как достать данные. это декларативный язык.
К сожалению, за это приходится платить производительностью приложения. Особенно это заметно, если на базе данных сидит много клиентов — универсальный сервер всегда проигрывает сугубо заточенному. Именно поэтому кобыла и сегодня живее всех живых.
Однако зачастую, в проект берут какую-нибудь MongoDB, потому что это стильно-модно-молодежно и начинают лабать коллекции со схемами и связами, с сложными выборками. Вот и получается что забивают гвозди микроскопом.
Почему SQL одерживает верх над NoSQL, и к чему это приведет в будущем