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

Эта статья для вас, если вы:


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

Моя статья не для вас, если вы:


  • хорошо умеете готовить свою любимую БД, оптимизировать индексы, настраивать и всякое такое;
  • имеете в штате хорошего специалист, который сможет аргументировано выбрать нужный вашему проекту вариант. специалист должен быть действительно хорошим, а не «экспертом на диване»;
  • обслуживаете проект с так называемым «big data», то есть у вас огромные базы, десятки или сотни серверов в кластере и всякое такое — ну у вас как бы должен быть в штате один или несколько специалистов.

О чем пойдет речь в статье?


Я разберу в своей статьи некоторые типичные и не очень варианты выбора баз данных, а если быть более точным — подходы к выбору. Когда следует остановится на том, что используют большинство, а когда можно и задуматься над новым и неизведанным. Я опишу СУБД MySQL, PostgreSQL, MongoDB, Redis, CouchDB/PouchDB и упомяну о Aerospike с Tarantool, парочку других — но в некоторых моментах конкретный выбор не настолько принципиален. Надо понимать, что лучше изначально правильно спроектировать структуру данных, чем выбрать СУБД, а потом уже пытаться придумывать, что в ней собственно хранить.
Итак, начнем.

Небольшие отступления:


  1. Мои выкладки не истина в последней инстанции. Какие-то выводы я делал на основе реального использования, какие-то на основе информации в интернете, обсуждения с другими людьми. Некоторые выводы сделаны на основе реальных задач, а некоторые в чисто теоретических идеях. Вся эта информация есть в том или ином виде на просторах интернета, но достаточно разрознена, я же постараюсь компактно описать в одном месте.
  2. Я рассматриваю только те продукты, которые на момент написания статьи активно развиваются и в то же время стабильно существуют в течении длительного времени. Опять же, на мой взгляд, одним из условий выбора чего-либо для своего проекта — чтобы продукт был достаточно стабильный, рабочий, имел большое и хорошо развитое сообщество, его использование не сопряжено с многодневными танцами с бубном и т.п. И что немаловажно — должна быть возможность официально воспользоваться коммерческой поддержкой и получить тем самым гарантии от разработчика. Следует учитывать, что есть множество других вариантов, но они либо сырые и для их сопровождения в проекте придется прикладывать дополнительные и нерациональные усилия. Либо гораздо менее успешны или популярны.
  3. Я с удовольствием почитаю ваше мнение в комментариях. И об описанных базах данных и не только. И не только я, думаю многим будет интересно почитать аргументированное мнение о какой либо базе данных.
  4. Самое важное и еще раз — здесь не пойдет речь про крупные проекты. В таких проектах обычно уже есть свой архитектор или знающий человек и достаточно средств, чтобы обеспечить оптимальный выбор. Хотя кто знает, может мои выкладки и им пригодятся.

Теперь давайте зададим себе вопросы:


  • Насколько вы консервативны, хотите и любите ли вникать во что-то новое?
  • Хотите не думать или наоборот хотите вникнуть досконально в устройство базы данных?
  • Насколько хорошие программисты в вашей команде, смогут ли они грамотно составить структуру БД или они уже являются отличными специалистами по какой-то одной СУБД?

Ответили? Точно? Тогда я перечислю СУБД и опишу в каком случае рекомендуется обратить на них внимание.

MySQL / MariaDB

Народная СУБД или «must have», есть практически на любом хостинге. Простая в установке, работает нормально без особых настроек. При должном подходе может гибко настраиваться под ваши нужды. Но есть и подводные камни, в некоторые случаях она будет тем самым узким горлышком и ваш проект будет тормозить, как бы вы не тюнинговали СУБД и структуру данных.
MySQL для вас, если:

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

Минусы? Их есть и вам следует выбрать другую СУБД, если увидите важное.

— посредственная производительность. Действительно низкая, как не тюнингуй. даже кластер не поможет особо (его еще настроить надо, ага, те еще танцы с бубном). Речь о цифрах порядка 20 МБайт/сек. Из личного опыта, на SSD дисках при таком потоке MySQL упирался в свой предел, не справлялся и тормозил, причем сервис настраивался несколько лет, использовались оптимальные для нагрузки настройки. Из коробки конфигурацию, думаю будет еще меньше планку иметь;
— изменение структуры данных может быть довольно трудоемким процессом, особенно при большом количество связей между данными в разных таблицах и даже при простом добавлении полей;
— чувствительность к нестабильности сервера. Особенно это влияет при использовании XtraDB от Percona. Если неправильно завершить MySQL, можно настолько поломать таблицы и базы данных, что восстановить можно будет только из полного бекапа, конечно, если вы их регулярно делаете. И поверьте, это случается всегда в самый неожиданный момент. Есть инструменты, которые в несложных ситуациях помогут восстановить работоспособность, но они не панацея. В последних и актуальных версиях активно борются с этим, заявлена гораздо лучшая стабильность и надежность.

PostgreSQL

Своего рода мастодонт, очень старая и грамотная СУБД. Она почти как MySQL, только лучше. Но надо уметь готовить и настраивать. По мнение многих, очень стабильная СУБД, ее практически невозможно уронить, порушить таблицы как в MySQL. И это может быть для вас решающим фактором при выборе.

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

— вы консерватор (понимаю повторяюсь, но так и есть) и нужно надежное хранилище;
— вы или ваш специалист умеете настроить и использовать PostgreSQL;
— вам нужны хорошо структурированные данные, но с некоторой гибкости в схеме данных (JSON/BJSON);
— при помощи сторонних библиотек просто и удобно расширяться в кластеры и делать шардинг таблиц. И все это действительно работает.

А минусов как то вот не особо описывать… Справедливости ради, особо практики не имел, в основном сужу по рассказам знакомых:

— необходимость опыта работы с этой СУБД, чтобы приготовить ее хорошо. Иначе лучше взять MySQL или прочитать дальше;
— система авторизации по умолчанию может вызвать затруднения при использовании или настройке, далеко не всем нравится, некоторые даже очень опытные разработчики до сих пор не до конца понимают как оно там работает.

MongoDB

О, сколько копий до сих пор ломается — SQL или NoSQL… Но все же в некоторых случаях MongoDB справляются с задачей гораздо лучше, чем MySQL или PostgreSQL. Например, реальный случай, свидетелем которого я был — сбор и обработка статистики по хостингу (нагрузка на CPU, i/o, память и т.п.) — MySQL не справился от слова вообще. MongoDB справился без особых проблем. База данных достигает объема в 200-300 ГБайт, поток данных достигает 100 и более МБайт/сек. Показательно, на мой взгляд.

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

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

Минусы тоже есть.

— Нет простых транзакций. По крайней мере в том, классическом виде, какие они есть в MySQL/PostgreSQL. При добавлении множества данных, которые зависят друг от друга, могут быть определенные трудности, которые придется решать самостоятельно на уровне кода. Ну то есть вы можете и не столкнутся конечно, но…;
— связность данных практически отсутствует. Сразу приходит на ум, постоянно упоминают JOIN из SQL — вот этого по сути нет. Хотя, если быть более точным, то надо просто мыслить другими категориями;
— нужно перестраивать мышление именно под NoSQL. иначе будет сложно сопровождать — то есть хороший программист (точнее архитектор ПО) обязателен в дальнейшем.

Redis

Чаще всего эту СУБД используют в качестве кеширующего слоя для работы с данными из другой, более медленной СУБД. Лучшая замена memcached, если вам это что-то скажет. Редко, но все же может использоваться в качестве самостоятельно БД для данных. При этом Redis умеет разные типы данных, в том числе списки, очереди, умеет Pub/Sub, а еще очень просто работать с TTL (время жизни ключа). Работает в памяти, очень быстрая, умеет сохранять данные на диске, причем с поддержкой дозаписи (гораздо меньше нагружает диск) и загружать при запуске. Почти сказка.

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

— объем данных небольшой и очень простая схема, укладывающая в шаблон «ключ=значение»;
— простая реализация репликации Master — Slave. Действительно очень простая настройка, достаточно добавить в конфиг сервера указания на мастера, запустить Redis Server и данные уже реплицируются. Хотя, наверное, следует уточнить, что настроить гибкую репликацию (частичную) вряд ли получится;
— нужен Pub/Sub (очереди). Справедливости ради следует сказать, что есть отдельные системы Pub/Sub, реализующие помимо этого паттерна и другие. Redis реализует это достаточно элегантно и просто, вполне возможно вам другие не понадобятся;
— нужен кеш для более медленной СУБД или просто хотите не задумываться о скорости работы СУБД с оглядкой на ее объем. Примером может послужить сайт на Drupal, с основной базой данных в MySQL и кешем в Redis. Проводил тесты ради интереса обычным ab, скорость отдачи контента может увеличится в разы. На обычном Apache + Redis + mod_php можно достичь сравнимой производительности с Nginx + php-fpm, а если к Nginx добавить Redis…

Минусы тоже есть, как же без них.

— объем данных не должен превышать объем свободного ОЗУ на вашем сервере (на самом деле может, но тогда все они будут уходить в swap, сильно замедлять работу, в общем лучше избегать);
— в угоду производительности присутствует довольно слабая сохранность данных. То есть вполне может произойти такое, что данные добавили, а после рестарта их нет. Включение AOL (append of file) немного сглаживает ситуацию, но тогда загрузка с диска будет довольно длительной;
— транзакции и связанные данные не то, чтобы умеет. Если точнее — есть Pipeline и Multi/Exec, но это все таки не совсем транзакция в классическом понимании;
— до сих пор не умеет нормально кластер и шардинг. Нормальной реализации до сих пор нет.

Конечно можно напрячься и сделать что-то похожее на кластер при помощи специального скрипта, но на мой взгляд выглядит это довольно кривовато и неоптимально.

Альтернативы


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

IBM Lotus Domino/Notes

На мой взгляд ярчайший пример успешного коммерческого проекта СУБД концепции NoSQL. Хотя подозреваю, что успех скорее не в его NoSQL, а в наличии полноценного сервера приложений с встроенным редактором кода и интерфейса к базе. Решение очень зрелое, существует на рынко довольно давно и поддерживается гигантом IBM — ну то есть очень даже круто. Лично участвовал в разработке двух разных систем электронного документооборота на его базе, а также сопровождал некоторые критично важные приложения в банке. Кстати, несмотря на платную политику распространения, мало кто знает, но его можно бесплатно скачать для изучения.

CouchDB

Хотите хранить документы разной структуры (ну как MongoDB, типа), но у вас нет для приложения адаптера или не хотите лишних зависимостей? CouchDB работает через http, имеет встроенный веб-сервер, обменивается в JSON. Очень удобно. Кстати умеет транзакции и можно подписываться на изменения данных. Но это не точно.

PouchDB

Это очень интересный проект, как бы аналог CouchDB, но более приземленный, встраиваемый вариант. Встроили в приложение, работает как локальная база данных, но умеет настраиваемую репликацию с CouchDB или PouchDB Server (на базе ExpressJS). PouchDB на самом деле скорее прослойка, где снаружи вы работаете с единым API, CouchDB-подобным, но внутри может быть совсем разные СУБД — и SQLite и LevelDB и браузерная база данных и MongoDB и даже MySQL. Очень пригодится, если вы делаете распределенное приложение, где обмен данными важен, но связь с сервером может быть нестабильной или эпизодической.

Aerospike

На мой взгляд отличная замена Redis в плане key/value БД. Умеет транзакции, умеет сохранность данных, умеет большой объем данных (превышающий объем доступной ОЗУ). Правда нет Pub/Sub и каких-то особых структур данных, но работает быстро и хорошо. Пожалуй единственным недостатком это слабая популярность по сравнению с Redis. Непонятно кстати почему…

Apache Cassandra

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

Tarantool

Замечательный проект от Mail.Ru. Что-то среднее между Redis/Aerospike и MongoDB… Хотя по моему сами разработчики до сих пор затрудняются провести аналогии :). Его надо уметь, а если быть более точным хотеть готовить. И речь не про настройку, а про постоянную подгонку под разработку новых версий Tarantool. Нужно хотеть вникать во внутреннее устройство этого проекта, постоянно изучать изменения его API и документации, все время подгонять код приложения под изменения. А если вы еще и хотите поучаствовать в процессе разработки, пообщаться с разработчиками в чате — тогда тем более это для вас.

А вот теперь как бы и все.

Да, я упомянул далеко не все СУБД (если смотреть на этом сайте, то там перечислено 253 названия). Надеюсь вы и не думали, что я их все перечислю?

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

UPD1: По поводу отказоустойчивости MySQL. Вы все правы. Я не заявляю, что InnoDB нестабильна, я лишь упомянул, что ситуация это возможна. И если она произойдет, то восстановить работоспособность никак нельзя будет, только начисто восстанавливать все целиком из бекапа. Именно об этом речь, а не о том, что вы решили будто я считаю ее нестабильной. По реальному примеру, на серверах у нас такое произошло за последний год 2 или 3 раза. На разных серверах. На сервере несколько сотен баз с разной нагрузкой, объемов и т.п. Это не значит, что у вас MySQL будет падать регулярно на виртуалке с одним-двумя сайтами, совсем не об этом речь. Как то так.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (71):

  1. maxel_e
    /#10676678

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

    • Softovick
      /#10676682 / -2

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

      • maxel_e
        /#10676688

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

        • Softovick
          /#10676698 / -1

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

        • Softovick
          /#10676706 / -1

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

    • Barafu
      /#10676784 / +1

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

  2. Gemorroj
    /#10676716 / +1

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


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

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

    • Softovick
      /#10676726 / -1

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

      • Gemorroj
        /#10676748

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

        • Softovick
          /#10676752

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

      • ZurgInq
        /#10677006

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

        • Softovick
          /#10677060

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

          • batment
            /#10677136

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

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

            • Softovick
              /#10677186

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

            • svetasmirnova
              /#10678680

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

              • Softovick
                /#10679102

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

                • svetasmirnova
                  /#10679190

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

                  • Softovick
                    /#10679266

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

                    • svetasmirnova
                      /#10679448

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

                      • Softovick
                        /#10679470

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

                        • svetasmirnova
                          /#10679526

                          Оно же сразу в лог ошибок пишет. У 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
                            /#10679548

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

  3. OlehR
    /#10676754

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

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

    • Softovick
      /#10676762

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

  4. Cobalt
    /#10677064

    А как же ClickHouse?

    • Softovick
      /#10677070

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

      • Cobalt
        /#10677110

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

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

        • Softovick
          /#10677180

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

          • gtbear
            /#10677468

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

            • Softovick
              /#10677476

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

  5. Softovick
    /#10677088

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

  6. qRoC
    /#10677104

    MongoDB справился без особых проблем. База данных достигает объема в 200-300 ГБайт, поток данных достигает 100 и более МБайт/сек.

    у вас планируется довольно серьезный объем данных (десятки или даже сотни ГБ), определить это даже на этапе ТЗ можно;

    Не совсем соглашусь, т.к. монга работает отлично пока хватает памяти.
    Плюс, по своим наблюдениям, скажу что она начинает медленней работать когда базу становится свыше 1Тб.
    Ну и добиться результатов свыше 100Мб/сек(а то и меньше) в реальных кейсах можно только с помощью bulk, иначе с ней могут произойти чудеса, когда даже findOne() уходит в бесконечное выполнение.

    — до сих пор не умеет нормально кластер и шардинг. Нормальной реализации до сих пор нет.

    Можно подробней в чём проблемы? Могу отметить что есть проблемы если master падает(проблемы на время пока slave не переключиться), но в целом вроде всё хорошо.

    Хотите тоже самое, что MongoDB, но у вас нет для приложения адаптера или не хотите лишних зависимостей?

    Couch(Base) совсем не тоже самое что и MongoDB.

    • Softovick
      /#10677164

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

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

      • qRoC
        /#10677224 / +1

        Про Redis речь не о репликации мастер-ведомый. Как раз репликация там очень хорошо сделана.

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

        Чтобы создать кластер и распределить данные между несколькими узлами, нужно иметь количество узлов, кратных 3 обязательно.

        то все не очень удобно — нельзя например создать кластер из 5 узлов или просто добавить 1 мастер, убрав другой мастер.

        Насчёт «кратных 3 обязательно» — не понимаю откуда взялась такая информация?
        Даже в документации приведён пример из 5 нод. (+ по слайву на каждый, итого 10)

        Создавать и добавлять узлы в кластере можно только при помощи скрипта специального на Ruby. И встречал упоминание, что работает это не всегда корректно и очевидно. Э Ах да, узлы еще должны работать с опцией cluster-enabled, при этом как обычные сервера они уже перестают быть доступными.

        С добавлением нод проблем нет вообще.
        Насчёт опции. У вас поведения редиса меняется — ели вы пойдёте на неправильный мастер, он Вам вернёт узел в котором лежат данные, собственно из-за этого и ограничение — Вам нужно знать веса что бы попадать с первого раза на нужный мастер.
        И в этом обычно нет проблем т.к. если разговор про Redis, то использовать один инстанс под всё, разграничивая номером БД это плохая практика.

        • Softovick
          /#10677226

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

          • qRoC
            /#10677244

            Да, правда всего из 6 мастеров.

            • Softovick
              /#10677282

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

              • qRoC
                /#10677496

                Да, чётное, количество подобрано исходя из данных которые лежат в редисе.
                Неважно кратное 3-м количество нод, 10, 100, или даже 2, к сожалению это влияет лишь на шанс падения всего кластера.

                • Softovick
                  /#10677514

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

                  • qRoC
                    /#10677578

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

  7. Desprit
    /#10677116

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

    • Softovick
      /#10677170

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

      • Desprit
        /#10677220

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

  8. ZeStas
    /#10677422

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

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


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

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

    • Softovick
      /#10677462

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

      • ZeStas
        /#10677592 / +1

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

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

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

        • Softovick
          /#10679174

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

  9. unitto1
    /#10677442

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

    • Softovick
      /#10677446

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

      • unitto1
        /#10677664 / +1

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

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

  10. JekaMas
    /#10677466 / +1

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

    • Softovick
      /#10677472

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

      • JekaMas
        /#10677490

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

        • Softovick
          /#10677494

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

          • JekaMas
            /#10677604

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

  11. valeriyk
    /#10677482

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

    • Softovick
      /#10677484

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

  12. aPiks
    /#10677640 / -2

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

    • Softovick
      /#10677688 / +2

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

  13. aPiks
    /#10677652

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

    • Softovick
      /#10677696

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

      • aPiks
        /#10677862 / -1

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

        • Softovick
          /#10678026

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

  14. ggo
    /#10678574

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

    • Softovick
      /#10679168

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

  15. svetasmirnova
    /#10678700 / +1

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

    • Softovick
      /#10679154

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

      • svetasmirnova
        /#10679186

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

        • Softovick
          /#10679272

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

          • svetasmirnova
            /#10679424

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

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

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


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

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


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

            • Softovick
              /#10679440

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