Рассуждение на тему, какую базу данных выбирать

[maxel_e]

MySql и Postgres для консерваторов, а какая sql база данных для прогрессивных джедаев?

[Softovick]

Для прогрессивных джедаев — облачные СУБД. Типа SQL Azure или Amazon Aurora. Но прогрессивен ли тот джедай, который использует только SQL?

[maxel_e]

Ни в коем случае не говорил, что использовать только SQL! Каждой бд своё место в экосистеме. Просто ничего не было сказано про решения от мелкософтных, оракл и тому подобных производителей, а были описаны решения только для «консерваторов» ))) Вот и возник вопрос.

[Softovick]

Ну вообще да, есть Oracle RDBMS и Microsoft SQL Server… Но на мой взгляд эти продукты имеют довольно узкое применение и используются они чаще в каких-то конкретных продуктах или специализированных проектах, где использовать другую СУБД разработчики не задумывали.

[Softovick]

К тому же прямо что-то кардинально интересного и нового по сравнению с MySQL или PostgreSQL они не предоставляют. Впрочем, может я просто не знаю о чем то супер важном.

[Barafu]

Tсли вы не можете назвать 3 причины, чтобы не использовать SQLite — используйте SQLite.

[Gemorroj]

Слишком нагнетаете вокруг MySQL. Складывается впечатление, что не умеете его готовить (а там, на самом деле, много что можно/нужно настраивать).

чувствительность к нестабильности сервера. Особенно это влияет при использовании InnoDB

тут как раз с точностью до наоборот. на innodb после покупки ораклом очень сильный идет акцент.

[Softovick]

Возможно и нагнетаю :) Наверное наболело, как никак более 7 лет на хостинге с MySQL варюсь, используем решение Percona. Насчет акцента не в курсе, буквально позавчера восстанавливали базы после падения и именно InnoDB… В MyISAM гораздо меньше таких проблем, но зато и меньшая производительность.

[Gemorroj]

https://dev.mysql.com/doc/relnotes/mysql/5.7/en/
потыкайте там по ссылкам внизу с изменениями. innodb да репликация в основном.
возможно, myisam нормально себя чувствуют, потому что на них нагрузка небольшая.

[Softovick]

Спасибо. Но возник вопрос, насколько лучше стало? Ну то есть совсем надежно или чуть надежнее? Ну вот например на уровне с PostgreSQL или все же не стоит сравнивать?

[ZurgInq]

MyISAM — уже много лет deprecated, InnoDB стал хранилищем по умолчанию c версии 5.5 которая вышла в 2009/2010. И именно InnoDB позиционируется как достаточно отказоустойчивое хранилище.
Проверьте свежесть MySql на вашем хостинге.

[Softovick]

Server version: 5.5.57-38.9 Percona Server (GPL), Release 38.9
Достаточно свежая?

[batment]

У Percona, насколько я помню, оригинальный InnoDB заменен собственным движком XtraDB, и если об этом не знать, можно подумать что работает действительно InnoDB. На вашем месте я попробовал бы воспроизвести проблему на MySQL от Oracle и сравнил результаты.

Ну и 5.5 версия достаточно стара, после нее было проведено много работы по улучшению стабильности.

[Softovick]

Верно. Надо подправить статью, спасибо за уточнение.

[svetasmirnova]

XtraDB это InnoDB с фичами Percona. Все bug fixes, new features портируются из InnoDB после каждого релиза. Там может что-то воспроизводиться, не воспроизводимое с MySQL, но это достаточно редкий случай. Скорее настройки надёжности отключены для большей производительности. innodb_double_write, innodb_flush_logs_at_trx_commit, вот это всё

[Softovick]

Нет, не отключены.

[svetasmirnova]

Опция innodb_force_recovery знакома? Файловая система какая?

[Softovick]

Ext4, и да, знакома. И да, часто innodb_force_recovery спасает. Но иногда, очень очень редко, все же даже она не справляется.

[svetasmirnova]

Бывает, да. Чаще всего когда диск полетел всё-таки.

[Softovick]

Ну выглядит это примерно так, например, внезапно перезагрузился сервер по питанию или закончилась память, не хватило swap — сервис MySQL аварийно завершается. Структура одной из таблиц нарушается. Это не всегда происходит конечно, но замечается не сразу, так как и checkfs и mysqlcheck -Ar обязательно делается, ругаться сервис перестает, ошибок на файловом уровне тоже нет. Но где-то вот какая то ошибка в структуре ждет своего часа и в один «прекрасный» момент начинает расти. Сначала начинает сыпать ошибками при работе с БД, где эта таблица. И если не принять меры, то есть как минимум все задампить, удалить и заного восстановить из дампов — то через какое-то время проблема начинает расти и влиять на работу уже других БД, вплоть до полной недоступности всех БД на сервере. И с таким мы реально сталкивались, мониторинг далеко не всегда спасает или дает сигнал, хотя без него ситуации повторялись бы наверное чаще.

[svetasmirnova]

Оно же сразу в лог ошибок пишет. У Percona есть такая опция, кстати: www.percona.com/doc/percona-server/LATEST/reliability/innodb_corrupt_table_action.html#innodb_corrupt_table_action Но да, перевосстановить таблицу придётся.

Вообще странно, что с innodb_doublewrite и innodb_flush_log_at_trx_commit=1 у вас такое регулярно происходит.

[Softovick]

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

[OlehR]

Раз стаття називается «Рассуждение на тему, какую базу данных выбирать» а не
«Рассуждение на тему, какую безплатную базу данных выбирать»

Если у вас есть деньги посмею дополнить:
MSSQL — мощная, легкая в администрировании.
ORACLE — наверное самая лутшая SQL БД з самим быстрим и мощным встроеним язиком PL/SQL (для любителей писать логику на БД)
Из недочотов — цена. Сложность администрирования.(с каждой новой реализацией становится проще)
Обе имеют Inmemory опции(очень разние по сути реализации).
Обе есть смисл покупать только в enterprise варианте, ибо вкусние плюшки только в enterprise редакции.

[Softovick]

Я не зря упомянул коммерческую поддержку от разработчиков. Она есть по моему в каждой из перечисленных СУБД. Насколько круче она в MS или Oracle — не знаю, но если у вас нет никакой СУБД, то чисто платную выбирать нужно только в том случае, если выбор оправдан.

[Cobalt]

А как же ClickHouse?

[Softovick]

Я читал про нее. Но вот рекомендовать в качестве БД для проекта… По описанию она предназначена для достаточно узкой ниши, обработки аналитических запросов. Она используется в Яндексе где только можно, но вот так чтобы кто-то еще помимо использовал, не встречал. Только упоминание про ЦЕРН и ТинкоффБанк. И там данные огого какие огромные, масштабы совсем не маленькие. У вас есть опыт реального использования?

[Cobalt]

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

Суть

В кратце: проект gps мониторинга сотовых телефонов. В ClickHouse таблица с координатами сотовых вышек. Соответственно представьте запрос чтобы выбрать координаты вышек для двух симочного телефона, учитывая что вышки могут быть записаны там по разному. Каждый телефон может присылать такие данные пакетами по 100 записей. В процессе разработки, в качестве сервера использовался специально vps с заниженными параметрами, ибо если на нем будет хорошо работать, то на нормальном железе тем более.

Как вывод, для задач, где не требуется обновление и удаление данных, где нужен супер-быстрый поиск в огромных объемах записей — клик хаус идеальное решение.

[Softovick]

Отличный пример! И он как раз о том, что решение достаточно нишевое, где альтернатив не так уж и много. Спасибо за описание, пригодится.

[gtbear]

ну сбор и анализ статистики нужен когда бизнес достигает определенных объемов. Так что ниша это достаточно важная и нужная. Я работал с КХ на бою и она достаточно хорошо себя ведет (в ней было несколько терабайт данных)

[Softovick]

Все верно :) Хотя и специально уточнял, что статья моя не для таких случаев.

[Softovick]

Дополнил по поводу MySQL, InnoDB. Судя по всему некоторые восприняли не совсем верно мое описание (или я не совсем ясно выразился для человека).

[Softovick]

Couchbase как бы тоже не совсем тоже самое, что и CouchDB… Надо подправить описание, речь про хранение документов без схемы конечно же.

Про Redis речь не о репликации мастер-ведомый. Как раз репликация там очень хорошо сделана. Чтобы создать кластер и распределить данные между несколькими узлами, нужно иметь количество узлов, кратных 3 обязательно. Создавать и добавлять узлы в кластере можно только при помощи скрипта специального на Ruby. И встречал упоминание, что работает это не всегда корректно и очевидно. Это все не очень удобно — нельзя например создать кластер из 5 узлов или просто добавить 1 мастер, убрав другой мастер. Ах да, узлы еще должны работать с опцией cluster-enabled, при этом как обычные сервера они уже перестают быть доступными. Довольно неудобное решение. Если я ошибаюсь, поправьте меня.

[Softovick]

А вы используете где-то такой кластер Redis?

[Softovick]

То есть все таки четное количество? Или это связано с объемом данных?

[Softovick]

Ну да, упадет один из мастеров и весь кластер недоступен… Это также работает и при большем, чем 3 мастера, количестве узлов?

[Desprit]

Еще одна хорошая БД прошла мимо статьи — RethinkDB, а у нее 20К звезд на GitHub.

[Softovick]

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

[Desprit]

По большому счету, это не так страшно. Даже после ее «закрытия» выкатывались новые минорные версии с небольшими фиксами. Надеюсь, что дальше будет как раньше :)
У нее просто потрясающий reql, ради него одного стоит хотя бы просто ознакомиться и потестить БД в небольших проектах, а там уж как пойдет.

[ZeStas]

MongoDB для вас, если:

— у вас нет четкой, заранее описанной структуры данных или вы предполагаете, что состав данных может потом сильно изменится (конечно это можно делать в SQL, но надо мыслить другими понятиями, поменять то можно, но вопрос насколько это будет трудоемко);

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

Пример во что может вылиться выбор NoSQL решения — Почему вы никогда не должны использовать MongoDB

[Softovick]

Ну не считая того, что та статья 2013 года… Говорится там примерно о том же самом :) Или нет?

[ZeStas]

По-моему там говорится как раз об обратном. Здесь посыл — «не знаешь, какая будет структура у базы данных — используй MongoDB». В той статье приводится кейс, когда люди выбрали MongoDB, у них поменялась схема, в результате пришлось убить уйму человекочасов, что бы переписать все на реляционную базу.

Так что совет, на мой взгляд должен звучать так — «выбирайте MongoDB, если у вас есть четкая схема данных, хорошо ложащаяся на данную СУБД и есть уверенность что в будущем эта схема таковой и останется.»

Если же у вы не знаете, какая у вас будет структура данных, то тут лучше смотреть на тот же PostgreSQL с возможностью работы с JSON.

[Softovick]

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

[unitto1]

Жаль что нет даже упоминания об NewSQL решениях. Например CockroachDB & OrientDB.

[Softovick]

Хорошее уточнение. А что вы можете о них рассказать?

[unitto1]

Честно говоря полевого опыта применения у меня пока нет, сейчас осваиваю таракана на пет проекте.

По тому что увидел в данный момент — OrientDB не имеет ODM (object document mapper) для пайтона (в офф. доке есть инфа только о драйвере и OGM — object graph mapper), потому освоение ее я пока отложил. А вот CockroachDB мне показался более приемлемым — у него прозрачное маштабирование и хорошая выживаемость кластера (N-1 / 2)%, плюс он предоставляет наружный интерфейс для PostgreSQL (практически все остальные NewSQL базы — предоставляют интерфейс от MySQL). Есть небольшие различия в деалектах, но для большинства языков разработчики уже предоставили либы для наиболее распространенной ORM с новым диалектом. Плюс естественно есть драйвера популярных языков.

[JekaMas]

Softovick Про Aerospike я бы мог добавить минусы, доводилось с ней работать и сертифицироваться: Enterprise версия догорая, а Community постепенно была урезана до того, что в кластере можно иметь не более 3х нод и есть ограницение на объем данных и нет возможности применять какие-либо изменения настроек кластера без его полной перезагрузки, включая добавление новой «базы» (в понятиях Aerospike это «namespace»).
Так что минусы достаточно значительны.

[Softovick]

Спасибо… А что за ограничение на объем данных, какого порядка?

[JekaMas]

Нашел подробности, ограничение не в объеме данных, а в consistensy. Так называемая «strong consistency» убрана из Community и будет жить только в Enterprise.

[Softovick]

Это что-то типа усиленной транзакции?

[JekaMas]

Это большие гарантии относительно weak consistency link

[valeriyk]

Можно еще было добавить вариант «когда вам на самом деле не нужна СУБД».

[Softovick]

Думаю это совсем другая тема для отдельной статьи…

[aPiks]

IBM Lotus Domino/Notes — это клиент почтовый и офисное ПО, а не СУБД.

[Softovick]

Я вас удивлю, но это не так. А если быть более точным, не совсем так. Если коротко, это инфраструктура, где есть и почтовый сервер, клиент и СУБД и сервер приложений и офисный пакет (он там был не всегда). Причем сервер приложений есть и в клиенте и в серверной части.

[aPiks]

И почему в статье не упоминается ORACLE БД?
Это одна из самых стабильных баз данных и одна из самых быстрых и масштабируемых.

[Softovick]

На мой взгляд, выбор системы, которая распространяется только на платной основе, должен быть аргументированным решением. Но по опыту чаще всего использование таких продуктов выглядит скорее выбором менеджмента или уже используемое ПО диктует свои условия — либо ты делаешь на этом, либо вообще не занимаешься проектом. И хоть обдаказывайся, что Oracle Database круче всех, а у заказчика инфраструктура на IBM Notes… Ну врядли. А теперь покажите мне небольшой проект, который способен выкупить лицензию на Oracle Database.

[aPiks]

А в статье где-то упоминается про то, что обзор будет только о БД и СУБД для нищих стартапов и фрилансеров?
С утверждением по поводу выбора менеджмента вообще не согласен. Чаще всего такого рода выбор стоит не перед менеджментом, а перед техническими лидерами компании. Они предлагают техническое решение для менеджеров и его стоимость, а менеджмент решает, могут ли они потратить на это такую сумму. По опыту, БД с хорошей поддержкой, стабильностью и развитым инструментарием, впоследствии экономит немало средств на отсутствии простоев и издержек. Если правильно преподнести это для менеджера — они не будут спорить. А когда тут недавно появилась статья, о том, что яндекс переехал на Постедж потому что Оракл дорогой — ну это просто смешно. Особенно, когда они вкладывают деньги в мертворожденные проекты, но при этом экономят на основах.

[Softovick]

Богатыми становятся не потому, что много тратят…

[ggo]

Лучше бы структурировали по характистикам:
— с поддержкой честного ACID, и без оного
— с поддержкой in-memory, и без оного
— с поддержкой шардинга, и без оного
— структуры (реляционные, графы, key-value, timeseries)
— с поддержкой constraints во всех проявлениях, и без оного
— c поддержкой бизнес-логики во всех проявлениях внутри бд, и без оного
— наверно можно еще продолжить
Это только то, что интересно разработчику. И не касались инструментов.
А есть еще operation staff. Есть бизнеса…

[Softovick]

Цель статьи была в другом. Хотя хорошая идея, смутно представляю, как это реализовать в рамках сообщества Хабра :)

[svetasmirnova]

Статья сплошной facepalm. MySQL без настроек заточен под очень слабую машину. Как минимум innodb_buffer_pool_size и innodb_log_file_size нужно поменять. Судя по тому, что автор пользуется хостингом, скорее всего, хостинг провайдер и настроил MySQL, а PostgreSQL нет :)

[Softovick]

Автор работает в хостинге, более 7 лет. И люди там работают, которые настройками и тюнингом занимались гораздо больше времени. Конечно при развитии проекта рано или поздно нужно настраивать и тюнинговать БД под реалии.

[svetasmirnova]

Зачем бред про работу на production из коробки пишете тогда?

[Softovick]

Что именно вы считаете бредом, приведите пример.

[svetasmirnova]

Я же написала в предыдущем комментарии.

MySQL для вас, если:

— вы консерватор и не хотите вникать в настройки СУБД, просто поставили и работает (ну или на хостинге используете то, что дают);

Впрочем вот это объясняет:

— вы новичОк и вам нужна СУБД для управления структурными данными, желательно небольшими (до 1 — 2 гигабайт).

Для 1-2 гигабайт нечасто обновляемых данных можно и с настройками по умолчанию жить.

[Softovick]

А я ведь не зря написал в начале статьи отступления, в частности про тех у кого много данных или кто любит свою БД и умеет ее готовит… А так Вы правы, но статья моя не для этого задумывалась.