Комментарии 106
Тщетно пытался найти в интернете хотя бы одну фразу из Вашего текста
атомарные пайплайны
sqd для строготипизированных языков
Что это. Остаюсь пока не узнаю на реляционных.
пусть они буду даже идеальными. но что будет с производительностью?
если еще учесть что современые разработчики привыкли делать ленивые транзакции — это когда каждая операция в транзакции отправляется на сервер отдельным запросом. все будет тормозить.
Пусть они были бы не идеальными, но меня и авторов jepsen вполне бы это устроило, если бы в документации об этом прямо писали — «транзакции» есть, но не ожидайте от них надежности реальных транзакций реляционных баз данных, где действительно есть железные гарантии.
Если даже отбросить необходимость транзакций. Предположим они совсем не нужны. У монги не нахожу преимуществ совсем. Элемпнтаные действия как то join которые все же там есть хоть и своеобразные или под чет количество строк это квест и не все его проходят. Мангус же этого не реализует. Уже не говорю об элементарном поиске по строке аналоге like. Поддерживаю несколько проектов на столе чужих. Одни траблы. А расхлябанность схеме данных совершает картину. Единственное что у монги на пять с плюсом это пиар. MEAN стек.
Пример из воздуха, надо было проверить гипотезы и "пощупать данные":
- на "кластер" монги из 3 машин(дев. ттх) 280 gb данных, 3 млрд записей — записывались данные и по 4 ключам-полям строился индекс 12 часов с небольшим.
- Те же данные почти тем же кодом записывались в кластер эластика из большего количества серверов и сервера были условно с прода — 29 часов.
Совсем не корректное сравнение. В еластике при этом строились индексы для поиска слов по всяким хитрым лингвистическим расстояниям слов (пропуски букв перестановки слов и т.п.) а в монге аж ничего. В том смысле что индексы которые строили многа это на дав-три порядка в десятичном исчислении более простые индексы чем строила эластика. А время различается в два раза всего
Я согласен, про корректность сравнения. Но вопрос стоял, что, нужно было искать по 4 ключам, а не по всем. Плюс для загрузки в эластик понадобился реальный кластер из реальных по ттх машин, а не 3 машинки, единственный плюс которых диски NVMe.
Но как-то не вижу надобности работать с джисонами без схемы
очевидно, что для тех случаев, когда схема меняется.
у меня, например, в одном проекте в json хранится лог: действие и атрибуты, список которых зависит от действия.
(речь не про монгу конкретно, а про «зачем может потребоваться schemaless»)
Не совсем понял, что не так с поиском по строке аналоге like? В монге это работает, и regexp работает. Отсутствие схемы — очень удобно, когда может прийти любой структуры документ. Индексы работают нормально, геоиндекс из коробки — отлично работает. Монга до определенных размеров очень быстро работает и на запись и на чтение. С монгой очень удобно работать, когда надо проанализировать данные, в отношении которых — не всегда очевидна структура документов, база занимает место — при определенных обстоятельствах, меньше других.
Работает полным перебором строк. В то же время в Postgresql bson поля индексируются и поиск идет в примеро с той же скоростью что и по простому текстовому полю
Не полным, постройте индекс по полю и сравните, также доступны text-search.
https://docs.mongodb.com/manual/reference/operator/query/regex/
Фактически оптимизируется только поиск по префиксу.
text-search это из другой оперы. Это токенизация текста и поиск по точному совпадению слов.
Каждая модель СУБД имеет свои плюшки, позволяющие наиболее эффективно решать определенные задачи.
Реляционные СУБД по моему опыту хороши как минимум тремя вещами:
- SQL — это фактически стандарт. И в реляционных СУБД его поддержка завсегда лучше, чем в альтернативных, особенно когда дело касается хранения действительно больших объемов данных.
- Многие представления предметных областей при хранении лучше таки ложатся на реляционную модель.
- Реляционное представление простое и понятное во всех отношениях.
Если же говорить о личных предпочтениях, то мне как-то больше по душе СУБД "ключ-значение". Особенно те, что основаны на MUMPS (их сейчас много развелось, и коммерческие есть, и свободные).
На некоторых задачах они как раз самыми быстрыми оказываются. Да и гибкость при решении различных задач просто запредельная.
Не согласен что SQL фактически стандарт — это реально стандарт
Это с какой стороны посмотреть.
SQL — это, конечно, реальный стандарт, но, как всегда, есть нюансы.
Во-первых, я больше не про сам SQL как язык, а про то, что при "общении" с базами данных как правило предпочитают использовать именно его, хотя часто без него можно прекрасно обойтись (в альтернативных СУБД часто есть механизмы доступа к данным без всякого SQL, позволяющие существенно увеличить скорость доступа на специфических задачах).
Во-вторых, стандарт стандартом, а какую СУБД не возьмешь, везде всплывают какие-то особенности, не позволяющие просто взять и сделать одно и то же единым образом в разных СУБД, если оно хоть немного выходит за рамки примитивных базовых конструкций.
"в альтернативных СУБД часто есть механизмы доступа к данным без всякого SQL, позволяющие существенно увеличить скорость доступа на специфических задачах"
Но ведь prepared запрос это по сути и есть та самая альтернатива, и вы можете "переписать драйвер" и получать сырые строчки, не думаю что там прямо большие накладные расходы. Честно говоря не очень представляю чем именно sql может реально замедлить обработку, единственное чего не будет это map reduce на роды хотя и для sql как языка это работает (exadata/impala/teradata)...
Честно говоря не очень представляю чем именно sql может реально замедлить обработку,
Если СУБД не реляционная, то SQL часто реализуется как еще один уровень над другими механизмами доступа к данным. Соответственно, в таких случаях использование SQL — это всегда дополнительные накладные расходы.
Но разработчики даже в таких случаях все равно часто избирают доступ через SQL, потому, что он привычнее.
Вы как-то, на мой взгляд, неправильно понимаете что такое sql, условно вы можете писать напрямую в бацткоде jvm или например на java и использовать jit оверхед по сути будет только на компиляцию (другой вариант c++ и машкоды) в принципе в теории на машкодах(ассемблере) можно быстрее на практике не всегда из них можно выжать лучший результат, потому большинство используют то что удобней. При этом не стоит забывать что часто сам overhead от подготовки плана выполнения и его исполнения по сравнению с операцтями ввода/вывода и поиска незначительный.
p.s. с появлением серверов с большим объёмом RAM и SSD во многих бд провели оптимизацию в связи с тем что соотношение накладных расходов поменялось и приоритеты немного сместились, причём т.к. движки больших рсубд штука не простая этот процесс шёл не быстро что позволило появится на свет многим узкоспециализированным (в т.ч. nosql ) решениям и занять нишу, за счёт лучшего использования новых возможностей оборудования. Однако сейчас если посмотреть на то что рассказывает к примеру оракл на своих конференциях, выходит что они постепенно поглощают этот функционал, а в след за ними пойдут и open source системы...
Вы как-то, на мой взгляд, неправильно понимаете что такое sql,
Я прекрасно понимаю, что такое SQL. Внезапно, это всего лишь язык такой, текстовый. Другой вопрос, чтобы реализовать SQL в конкретной СУБД, нужно сделать очень многое. Без качественной и эффективной реализации всех этапов исполнения SQL запроса от интерпретации запроса до выдачи результатов в этом самом SQL особого смысла нет.
При этом не стоит забывать что часто сам overhead от подготовки плана выполнения и его исполнения по сравнению с операцтями ввода/вывода и поиска незначительный.
При некоторых условиях дополнительный расход ресурсов на все операции при исполнении запроса помимо ввода/вывода и поиска может быть достаточно значительным, чтобы обратить на это внимание.
Кроме того, построенный план запроса может оказаться очень неоптимальным, что приведет к значительному увеличению операций ввода/вывода и поиска. А при большом количестве динамически генерируемых сложных запросов это может стать реальной проблемой даже в ведущих реляционных СУБД, где на этих вопросах разработчики не одну собаку съели.
что позволило появится на свет многим узкоспециализированным (в т.ч. nosql ) решениям и занять нишу, за счёт лучшего использования новых возможностей оборудования
NoSQL СУБД выигрывают не за счет "лучшего использования новых возможностей оборудования", а за счет принципиально иной организации хранения данных, которая на специфических задачах (часто весьма специфических), дает реальный выигрыш в производительности доступа к этим данным.
хмм… захотелось подробнее прочитать о ClickHouse от Яндекса, эта СУБД вроде вообще относительно недавняя
Спасибо за статью, подчеркнул много нового для себя.
Спасибо за статью, однозначно в избранное.
Очень содержательная статья. Я только начинаю работать с бд, но мне очень понравился sql. Всегда интеесовал вопрос, а в чем различие MariaDB и MySQL, где-то я читал, что это разные базы, но кто-то говорит, что это одно и то же.
Понятно, что пользователи в России есть, но, полагаю, в основном это компании, ориентированные на западные рынки (особенно в свете недавних ковровых блокировок Роскомнадзором огромных подсетей c миллионами адресов AWS)
Плюсы для пользователей — это когда все ведущие компании представлены на рынке и жестко конкурируют. Тогда растет качество и падают цены. У всех облаков цены падают непрерывно — только последнее изменение биллинга лямбд в AWS до миллисекунд уменьшило у некоторых компаний счета за этот сервис в разы. Законы рынка еще никто не обманул.
Сейчас бы бесплатный постгрес покупать, ага. Купить за деньги можно Postgresql pro, но, откровенно говоря, я знаю буквально единицы случаев когда поддержка и/или дополнительные плюшки pro версии перевешивали бесплатность community версии.
да ну как вам сказать. если бы бюджет был бы бесконечный, то разве плохо иметь поддержку?
А вы не пробовали посмотреть список основных коммитеров и кто где работает? не в таких «паразитирующих» компаниях ли подавляющее большинство? )
Тут есть два факта:
- разработчику postgres надо кушать;
- проект большой, уделять ему пару воскресений в месяц не выйдет.
По сути выход один: работодатель должен оплачивать работу над postgres'ом.
Сразу видно того, кто не особенно разбирался в данном вопросе.
Community версия регулярно получает всякие плюшки из pro, просто это происходит на пару версий позже. И такой подход весьма часто встречается в различном софте. Разработчики этих самых плюшек тоже, знаете ли, хотят кушать, а работа над ними часто занимает очень много времен. Буквально на уровне несовместимости с "поковырять в свободное время".
Смотря для какого проекта и для чего, представьте большой банк который вдруг стал основным банком обороне и оракл ему не положен и попробуйте оценить плюшки pro версии с т.з. такого заказчика...
Ещё бы интересно было бы почитать про технические отличия разных БД (максимальные размеры БД, поддерживаемые размеры ячеек и т.д.)
О каких именно "много ограничений" SQLite вы пишите? Желательно в сравнении с аналогичными величинами другой СУБД
ИМХО статья очень разнонаправленная и по верхам. Очень много вольностей в трактовках. Особо опечалило описание rdbms. RDBMS в отличии от всех новомодностей основны на мат модели, и выполняют требования ACID. Что делает допустимым применение только ее, например, в транзакциях денег.Все эти супер новые технологии были реализованы в том или ином виде. Как расширения.
Но никто не хочет вникать. Основной тренд последних лет — не изучать, а хайповать "новые технологии". Зачем изучать теорию и методики нормализации, принципы хранения данных, проводить семантическое моделирование, изучать аналитику в sql. 99% современных тн дата саентистов, думаю, кроме простейшего селекта с группировками и не знают.
Была попытка сделать объектно редакционную субд… Lotus Notes.
Но, не взлетело. Тогда тоже… Трубили фанфары про конец ркляционных бд… Лет 20 назад.
Так будет со всеми этими поделками.
Любая мяу атака и все эти ваши тараниулы с редисками… пишут письма мелким почерком.
Но никто не хочет вникать. Основной тренд последних лет
Больше похоже, что вам не хочется вникать, если вас причина хайпа и популярности основана на нежелании что-то изучать.
Любая мяу атака и все эти ваши тараниулы с редисками… пишут письма мелким почерком.
При чем тут мяу атака? Она точно так же положит любой постгре и мускл, торчащий в интернет с паролей postgres:postgres. Без кэша из тарантулов и редисок все эти ваши RDBMS непригодны хоть для какого-то хайлоада. А скейлить их приходится все теми же самыми техниками из «новомодностей». Либо вообще выкидывать на помойку, чтобы не обкладывать костылями то, что не работает.
Без кэша из тарантулов и редисок все эти ваши RDBMS непригодны хоть для какого-то хайлоада.
Ничего похожего. Даже старую MySQL можно было вылизать. Чуток архитектуры, щепотку нормализации, изрядная доля мозгов и вот мы уже со скоростью свиста оперируем таблицами с миллиардом строк.
Еще отдельно хотел бы упомянуть, что реальный хайлоад — штука довольно редкая и закладывать все и вся под него не стоит.
сотню тысяч IOPS-ов
Ну это довольно смешная нагрузка все же. Конечно подобное может и один сервер переварит.
uber тоже испольует mysql но это не совсем тот mysql к которому мы привыкли см. https://habr.com/ru/post/354050/
Специалистов по настройке Postgres/Mysql котрые могли бы оптимизировать железо/софт чтобы работало не так уж много. Для фейсбука наверное полюбому не подошло. Но ОК/ВК модно было бы скорее всего и оптимизщировать. Плюс сейчас есть направление к протоколам MySQL/Postgresql создавать кластерные БД. Уже есть как минимум три очень популярные. Они и реляционные и кластерные одновременно.
На мой взгляд, привлекая внимание к вк/фб и т.п. нужно не забывать о контексте в котором совершался выбор того или другого продукта для старта, начиная от даты(сервера меняются и то для чего в 2000м нужен был большой шкаф сейчас может работать в коробочке с пассивным охлаждением) и заканчивая финансовыми возможностями (может у фб с текущими доходами всё получилось бы проще на oracle и железе от ibm, только тогда это было очень дорого для них).
Ну вот про Tarantool вы зря так. Там, ЕМНИП, ACID by design заложен, по крайней мере в пределах одного инстанса приложения. Оно попросту однопоточное, это даже преподносилось как плюшка и одна из главных причин высокой производительности: никаких затратных межядерных синхронизаций и блокировок.
Ну и как замену "взрослым" RDBMS никто tarantool серьёзно и не позиционировал. У него другая область применения и в ней он на самом деле хорош.
eumorozov Всё же обычно ora-xxxx ищется сразу и часто это ресурс оракл и если это не ora-00600 то ответ очень легко получить и это очень маловероятно "корректный запрос", всё же оракл очень удачно выбрал формат нумерации ошибок…
x67 Про поддержку ну это такое если вы не человек в очень крупной компании с доступом к поддержке, проще интернет, а вот закрытый metalink это проблема (некоторые проблемы могут иметь уникальное решение которое может не входить в общие патчи, насколько я знаю).
Проблемы на стыке, наверное у меня уже глаз замылился, но бд при использовании стандартных драйверов и sql эта не та штука которая настолько тесно интегрируется с другими продуктами что нужно искать сочетание django + bd… Тем и силён sql что он прост как… Ну по крайней мере в основном...
Про заплатить — теперь есть облака (90 т.р. в мес и у вас 4 быстрых ядра при загрузке 100% 24/7 терабайт хранения и куча плюшек(как и минусов)).
Про специалистов, а чем оракл сложнее postgre? Настраивается элементарно, инструментов вагон и тележка, гайдов полно… Думаю высшего технического без ИТ за глаза хватит как и для большинства современных продуктов.
p.s. и как бы я не любил opensource приходится признавать что то что в оракл часто просто работает (и даже если очень криво писать запросы) в opensource базах иногда не хочет. Мне очень нравился в своё время Firebird но по возможностям написания для внутреннего софта он сильно отставал, ведь если мы говорим не об ит компании то часто в такой компании пара специалистов и знать всё очень сложно, не говоря уже о вечном беге за отправляющимся паровозом новых технологий.
Видел использование и в больших, и в маленьких проектах. В маленьких бесплатных, как правило, не возникало обычно никаких проблем, т.к. весь базовый функционал который требуется в маленьком проекте вылизан у Оракла до идеала, проблемы могут возникать в специфике, да и то легко обходились небольшими костылями
p.s. ошибки для оракл вообще не частая вещь, за 10 лет было две, одна очень плохая — view со сложным запросом с with recursive выдавал 0 строк всегда и молча (запрос не во всю работал версия 11.2.0.х), вторая менее страшная, после обновления с 11.2.0.4 на 12.2.0.1 один сложный запрос начал падать (много with с многократным ступенчатым использованием подзапросов, не мой...) просто пришлось переписать по другому...
Если покупают за чужие деньги (тонкий намек на систему откатов)
от же любимый вами AWS, Uber, Google, Facebook, Netflix, и так далее — все они почему-то Oracle не используют, насколько я знаю.Все верно. Эти компании (заметим, профильные в ИТ) с массой, сравнимой с Ораклом, могут себе позволить собственные разработки с собственной поддержкой.
При этом платить на сторону невыгодно.
Амазон, кстати, активно использовал Оракл до последнего времени и только последние несколько лет как перешел на другие СУБД. Можно за многое ругать Ларри и его компанию, но продукт для своего времени (конец 90х-начало 2000х) был отличный.
И вот совершенно точно припоминаю, что когда читаешь про известные компании, у которых сервера обслуживают пользователей со всего мира, то там никогда не упоминается оракле. Тот же любимый вами AWS, Uber, Google, Facebook, Netflix, и так далее — все они почему-то Oracle не используют, насколько я знаю.
проблема скорее не в том, что у oracle плохой продукт, а в том, что за него хотят много денег.
для мелких-средних проектов он слишком дорог, проще взять что-то опенсорсное (да даже и платное, но не столь дорогое), для совсем крупных слишком дорог, проще держать высококлассных разработчиков, которые пилят своё/дорабатывают опенсорсное.
остаётся всякий крупный не-IT бизнес, те же банки
Просто об этом предпочитают молчать. И на сайтах не указывать.
Про сыр в мышеловке напоминает это
Есть еще orientdb и arangodb где кстати гибридные то есть графы плюс документы. Последнюю из них пытаюсь задействовать в текущем проекте. Вцелом те же рсубд только с возможностью делать рекурентные запросы, хотя рсубд также могут это
Но рано или поздно начнёт возникать ситуация, что ваша БД не успевает записывать.… Это называется Master-Master.
Ммм, а почему вы так говорите, будто мастер1 станет писать меньше данных? С чего бы? Объём записи от появления мастер-мастер репликации не уменьшится никак. Мастер1 будет писать то что ему приложения сказали писать, плюс весь поток изменений от мастер2. Аналогично дела у мастер2. Каждая реплика будет писать совокупный объём данных, записанных на оба мастера.
Мастер-мастер — это совсем не про масштабирование записи. Про масштабирование записи шардинг.
Шутка ли тысячи светлых голов коммитят в репозитории качественный код, тестируют на реальных проектах и денег не просят.
Упоминание тысяч участвующих вызывает лишь улыбку. Вот PostgreSQL большой и известный проект? Как думаете, сколько человек участвует в разработке? Много наверное, со всего мира люди трудятся. Но просто посмотрим в release notes:
The following individuals (in alphabetical order) have contributed to this release as patch authors, committers, reviewers, testers, or reporters of issues.
И вот это вот всё суммарно 380 имён для 13 версии. Тысячи?
Тысячи разработчиков — это как раз про коммерческие СУБД. Сколько там у оракла? «38,000 developers and engineers». Даже если всего 1% из них занимается кодом базы — это по-прежнему больше в несколько раз, чем работает над кодом postgresql. А потом учесть сколько людей занимаются кодом fulltime, а кто в свободное время напишет пару patch review на интересные лично для него штуки (и уже попадёт в список контрибьюторов).
1% от 38 000 человек — это как раз 380 человек
Возможно, конечно, что это дополнение не настолько сильно увеличит число 38000 по сравнению с уменьшением списка контрибьюторов postgresql после исключения багрепортов. Но вот предположение, что действительно только 1% работает над базой — весьма сомнительно.
Тут ведь как считать, есть поддержка по регионам, есть обеспечение (логистика/доставка) есть разработка оборудования (хexadata вплоть до собственных чипов) есть java есть датацентры и их сотрудники куча продуктов вокруг (аналитика и т.п.) и даже бухгалтер есть Так что ИМХО 1% это хороший процент для работы над ядром и багфиксами...
Ммм, а почему вы так говорите, будто мастер1 станет писать меньше данных?
Чтобы не возникало недопонимания дополнил текст "… ваша БД не успевает записывать из-за общей нагрузки.". Обычно помимо нагрузки на запись есть ещё нагрузка на чтение.
Пример с прошлой недели, проект распределен по датацентрам (и шардинг там тоже есть) начинаются очереди сообщений на RabbitMQ, мониторинг Zabbix фиксирует повышение нагрузки на разных хостах одного датацентра. Часть сайтов через переключатель CDN переводится на другой хостинг, часть остаётся и уравновешивается нагрузка. Запись идёт в оба master, они синхронизируют изменения, которых не стало меньше, но проблем стало меньше, сайты не 500-ят.
Упоминание тысяч участвующих вызывает лишь улыбку. Вот PostgreSQL...
Фраза про open source проекты в целом, никакие конкретные СУБД не упоминаются. Если вспоминать про PostgreSQL, до 13 версии тоже наверняка был кто-то.
Также несогласен в том, что хранение JSON/XML это великое благо принесённое в реляционные СУБД. Но, к сожалению вместо развития сложных типов вроде координат и геометрии реляционные СУБД пошли на хранение структурированных (JSON/XML) и типизированных данных в столбцах таблиц.
Впрочем, моё мнение, несмотря на всё неприятие разрушения реляционной модели не является единственно верным.
Также могу отметить, что мне встречались ситуации, когда реляционная СУДБ не до конца отвечала требованиям решения и приходилось создавать некий гибрид из быстрого хранилища для поглощения входящих данных, реляционной СУБД для обработки и OLAP для архива и мономерных отчётов.
… но БД NOSQL появились несколько раньше, чем SQL
В статье написано про термин NoSQL. Он появился уже позже. en.wikipedia.org/wiki/NoSQL
Также несогласен в том, что хранение JSON/XML это великое благо…
Это не описано как благо, а как существующая реальность и фича СУБД. Нравится это или нет, но так есть. В реляционные БД их пишут, а потом ещё и строят поверх индексы JSON или XML.
Базы данных. Тенденции общемировые и в России