Эта статья для вас, если вы:
- выбираете базу данных для нового проекта и изучаете информацию про разные варианты;
- считаете, что текущая база данных не устраивает вас по каким то параметрам и вы хотите ее сменить, но у вас нет хорошего специалиста;
- просто хотите почитать в одной статье про несколько баз данных и когда можно их использовать.
Моя статья не для вас, если вы:
- хорошо умеете готовить свою любимую БД, оптимизировать индексы, настраивать и всякое такое;
- имеете в штате хорошего специалист, который сможет аргументировано выбрать нужный вашему проекту вариант. специалист должен быть действительно хорошим, а не «экспертом на диване»;
- обслуживаете проект с так называемым «big data», то есть у вас огромные базы, десятки или сотни серверов в кластере и всякое такое — ну у вас как бы должен быть в штате один или несколько специалистов.
О чем пойдет речь в статье?
Я разберу в своей статьи некоторые типичные и не очень варианты выбора баз данных, а если быть более точным — подходы к выбору. Когда следует остановится на том, что используют большинство, а когда можно и задуматься над новым и неизведанным. Я опишу СУБД MySQL, PostgreSQL, MongoDB, Redis, CouchDB/PouchDB и упомяну о Aerospike с Tarantool, парочку других — но в некоторых моментах конкретный выбор не настолько принципиален. Надо понимать, что лучше изначально правильно спроектировать структуру данных, чем выбрать СУБД, а потом уже пытаться придумывать, что в ней собственно хранить.
Итак, начнем.
Небольшие отступления:
- Мои выкладки не истина в последней инстанции. Какие-то выводы я делал на основе реального использования, какие-то на основе информации в интернете, обсуждения с другими людьми. Некоторые выводы сделаны на основе реальных задач, а некоторые в чисто теоретических идеях. Вся эта информация есть в том или ином виде на просторах интернета, но достаточно разрознена, я же постараюсь компактно описать в одном месте.
- Я рассматриваю только те продукты, которые на момент написания статьи активно развиваются и в то же время стабильно существуют в течении длительного времени. Опять же, на мой взгляд, одним из условий выбора чего-либо для своего проекта — чтобы продукт был достаточно стабильный, рабочий, имел большое и хорошо развитое сообщество, его использование не сопряжено с многодневными танцами с бубном и т.п. И что немаловажно — должна быть возможность официально воспользоваться коммерческой поддержкой и получить тем самым гарантии от разработчика. Следует учитывать, что есть множество других вариантов, но они либо сырые и для их сопровождения в проекте придется прикладывать дополнительные и нерациональные усилия. Либо гораздо менее успешны или популярны.
- Я с удовольствием почитаю ваше мнение в комментариях. И об описанных базах данных и не только. И не только я, думаю многим будет интересно почитать аргументированное мнение о какой либо базе данных.
- Самое важное и еще раз — здесь не пойдет речь про крупные проекты. В таких проектах обычно уже есть свой архитектор или знающий человек и достаточно средств, чтобы обеспечить оптимальный выбор. Хотя кто знает, может мои выкладки и им пригодятся.
Теперь давайте зададим себе вопросы:
- Насколько вы консервативны, хотите и любите ли вникать во что-то новое?
- Хотите не думать или наоборот хотите вникнуть досконально в устройство базы данных?
- Насколько хорошие программисты в вашей команде, смогут ли они грамотно составить структуру БД или они уже являются отличными специалистами по какой-то одной СУБД?
Ответили? Точно? Тогда я перечислю СУБД и опишу в каком случае рекомендуется обратить на них внимание.
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)
Gemorroj
19.02.2018 10:16+1Слишком нагнетаете вокруг MySQL. Складывается впечатление, что не умеете его готовить (а там, на самом деле, много что можно/нужно настраивать).
чувствительность к нестабильности сервера. Особенно это влияет при использовании InnoDB
тут как раз с точностью до наоборот. на innodb после покупки ораклом очень сильный идет акцент.
Softovick Автор
19.02.2018 10:20-1Возможно и нагнетаю :) Наверное наболело, как никак более 7 лет на хостинге с MySQL варюсь, используем решение Percona. Насчет акцента не в курсе, буквально позавчера восстанавливали базы после падения и именно InnoDB… В MyISAM гораздо меньше таких проблем, но зато и меньшая производительность.
Gemorroj
19.02.2018 10:28https://dev.mysql.com/doc/relnotes/mysql/5.7/en/
потыкайте там по ссылкам внизу с изменениями. innodb да репликация в основном.
возможно, myisam нормально себя чувствуют, потому что на них нагрузка небольшая.Softovick Автор
19.02.2018 10:32Спасибо. Но возник вопрос, насколько лучше стало? Ну то есть совсем надежно или чуть надежнее? Ну вот например на уровне с PostgreSQL или все же не стоит сравнивать?
ZurgInq
19.02.2018 12:36MyISAM — уже много лет deprecated, InnoDB стал хранилищем по умолчанию c версии 5.5 которая вышла в 2009/2010. И именно InnoDB позиционируется как достаточно отказоустойчивое хранилище.
Проверьте свежесть MySql на вашем хостинге.Softovick Автор
19.02.2018 12:53Server version: 5.5.57-38.9 Percona Server (GPL), Release 38.9
Достаточно свежая?
batment
19.02.2018 13:31У Percona, насколько я помню, оригинальный InnoDB заменен собственным движком XtraDB, и если об этом не знать, можно подумать что работает действительно InnoDB. На вашем месте я попробовал бы воспроизвести проблему на MySQL от Oracle и сравнил результаты.
Ну и 5.5 версия достаточно стара, после нее было проведено много работы по улучшению стабильности.
svetasmirnova
20.02.2018 11:01XtraDB это InnoDB с фичами Percona. Все bug fixes, new features портируются из InnoDB после каждого релиза. Там может что-то воспроизводиться, не воспроизводимое с MySQL, но это достаточно редкий случай. Скорее настройки надёжности отключены для большей производительности. innodb_double_write, innodb_flush_logs_at_trx_commit, вот это всё
Softovick Автор
20.02.2018 13:05Нет, не отключены.
svetasmirnova
20.02.2018 13:40Опция innodb_force_recovery знакома? Файловая система какая?
Softovick Автор
20.02.2018 14:08Ext4, и да, знакома. И да, часто innodb_force_recovery спасает. Но иногда, очень очень редко, все же даже она не справляется.
svetasmirnova
20.02.2018 15:10Бывает, да. Чаще всего когда диск полетел всё-таки.
Softovick Автор
20.02.2018 15:17Ну выглядит это примерно так, например, внезапно перезагрузился сервер по питанию или закончилась память, не хватило swap — сервис MySQL аварийно завершается. Структура одной из таблиц нарушается. Это не всегда происходит конечно, но замечается не сразу, так как и checkfs и mysqlcheck -Ar обязательно делается, ругаться сервис перестает, ошибок на файловом уровне тоже нет. Но где-то вот какая то ошибка в структуре ждет своего часа и в один «прекрасный» момент начинает расти. Сначала начинает сыпать ошибками при работе с БД, где эта таблица. И если не принять меры, то есть как минимум все задампить, удалить и заного восстановить из дампов — то через какое-то время проблема начинает расти и влиять на работу уже других БД, вплоть до полной недоступности всех БД на сервере. И с таким мы реально сталкивались, мониторинг далеко не всегда спасает или дает сигнал, хотя без него ситуации повторялись бы наверное чаще.
svetasmirnova
20.02.2018 15:33Оно же сразу в лог ошибок пишет. У 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 Автор
20.02.2018 15:43Я не писал, что регулярно :) Я писал, что он очень редко может произойти и когда произойдет, это плохо чинится.
В логах не пишется или не сразу начинает писаться, в том и дело.
OlehR
19.02.2018 10:33Раз стаття називается «Рассуждение на тему, какую базу данных выбирать» а не
«Рассуждение на тему, какую безплатную базу данных выбирать»
Если у вас есть деньги посмею дополнить:
MSSQL — мощная, легкая в администрировании.
ORACLE — наверное самая лутшая SQL БД з самим быстрим и мощным встроеним язиком PL/SQL (для любителей писать логику на БД)
Из недочотов — цена. Сложность администрирования.(с каждой новой реализацией становится проще)
Обе имеют Inmemory опции(очень разние по сути реализации).
Обе есть смисл покупать только в enterprise варианте, ибо вкусние плюшки только в enterprise редакции.
Softovick Автор
19.02.2018 10:35Я не зря упомянул коммерческую поддержку от разработчиков. Она есть по моему в каждой из перечисленных СУБД. Насколько круче она в MS или Oracle — не знаю, но если у вас нет никакой СУБД, то чисто платную выбирать нужно только в том случае, если выбор оправдан.
Cobalt
19.02.2018 12:54А как же ClickHouse?
Softovick Автор
19.02.2018 12:57Я читал про нее. Но вот рекомендовать в качестве БД для проекта… По описанию она предназначена для достаточно узкой ниши, обработки аналитических запросов. Она используется в Яндексе где только можно, но вот так чтобы кто-то еще помимо использовал, не встречал. Только упоминание про ЦЕРН и ТинкоффБанк. И там данные огого какие огромные, масштабы совсем не маленькие. У вас есть опыт реального использования?
Cobalt
19.02.2018 13:22Недавно столкнулся с ней на реальном проекте. Там требовалось делать выборку из огромнейшего числа записей по очень сложной схеме. Скорость работы просто поражает. И это на специально купленном для тестов железе.
СутьВ кратце: проект gps мониторинга сотовых телефонов. В ClickHouse таблица с координатами сотовых вышек. Соответственно представьте запрос чтобы выбрать координаты вышек для двух симочного телефона, учитывая что вышки могут быть записаны там по разному. Каждый телефон может присылать такие данные пакетами по 100 записей. В процессе разработки, в качестве сервера использовался специально vps с заниженными параметрами, ибо если на нем будет хорошо работать, то на нормальном железе тем более.Softovick Автор
19.02.2018 13:47Отличный пример! И он как раз о том, что решение достаточно нишевое, где альтернатив не так уж и много. Спасибо за описание, пригодится.
gtbear
19.02.2018 15:27ну сбор и анализ статистики нужен когда бизнес достигает определенных объемов. Так что ниша это достаточно важная и нужная. Я работал с КХ на бою и она достаточно хорошо себя ведет (в ней было несколько терабайт данных)
Softovick Автор
19.02.2018 15:29Все верно :) Хотя и специально уточнял, что статья моя не для таких случаев.
Softovick Автор
19.02.2018 13:10Дополнил по поводу MySQL, InnoDB. Судя по всему некоторые восприняли не совсем верно мое описание (или я не совсем ясно выразился для человека).
qRoC
19.02.2018 13:21MongoDB справился без особых проблем. База данных достигает объема в 200-300 ГБайт, поток данных достигает 100 и более МБайт/сек.
у вас планируется довольно серьезный объем данных (десятки или даже сотни ГБ), определить это даже на этапе ТЗ можно;
Не совсем соглашусь, т.к. монга работает отлично пока хватает памяти.
Плюс, по своим наблюдениям, скажу что она начинает медленней работать когда базу становится свыше 1Тб.
Ну и добиться результатов свыше 100Мб/сек(а то и меньше) в реальных кейсах можно только с помощью bulk, иначе с ней могут произойти чудеса, когда даже findOne() уходит в бесконечное выполнение.
— до сих пор не умеет нормально кластер и шардинг. Нормальной реализации до сих пор нет.
Можно подробней в чём проблемы? Могу отметить что есть проблемы если master падает(проблемы на время пока slave не переключиться), но в целом вроде всё хорошо.
Хотите тоже самое, что MongoDB, но у вас нет для приложения адаптера или не хотите лишних зависимостей?
Couch(Base) совсем не тоже самое что и MongoDB.Softovick Автор
19.02.2018 13:42Couchbase как бы тоже не совсем тоже самое, что и CouchDB… Надо подправить описание, речь про хранение документов без схемы конечно же.
Про Redis речь не о репликации мастер-ведомый. Как раз репликация там очень хорошо сделана. Чтобы создать кластер и распределить данные между несколькими узлами, нужно иметь количество узлов, кратных 3 обязательно. Создавать и добавлять узлы в кластере можно только при помощи скрипта специального на Ruby. И встречал упоминание, что работает это не всегда корректно и очевидно. Это все не очень удобно — нельзя например создать кластер из 5 узлов или просто добавить 1 мастер, убрав другой мастер. Ах да, узлы еще должны работать с опцией cluster-enabled, при этом как обычные сервера они уже перестают быть доступными. Довольно неудобное решение. Если я ошибаюсь, поправьте меня.qRoC
19.02.2018 14:04+1Про Redis речь не о репликации мастер-ведомый. Как раз репликация там очень хорошо сделана.
Вы кластер без слейвов не поднимите. По сути в редисе шардирование идёт по хешу ключа, каждый мастер обслуживает свою пачку слотов, соотвественно при падении одного мастера, его работу сможет подхватить слейв, но никак не другой мастер.
Чтобы создать кластер и распределить данные между несколькими узлами, нужно иметь количество узлов, кратных 3 обязательно.
то все не очень удобно — нельзя например создать кластер из 5 узлов или просто добавить 1 мастер, убрав другой мастер.
Насчёт «кратных 3 обязательно» — не понимаю откуда взялась такая информация?
Даже в документации приведён пример из 5 нод. (+ по слайву на каждый, итого 10)
Создавать и добавлять узлы в кластере можно только при помощи скрипта специального на Ruby. И встречал упоминание, что работает это не всегда корректно и очевидно. Э Ах да, узлы еще должны работать с опцией cluster-enabled, при этом как обычные сервера они уже перестают быть доступными.
С добавлением нод проблем нет вообще.
Насчёт опции. У вас поведения редиса меняется — ели вы пойдёте на неправильный мастер, он Вам вернёт узел в котором лежат данные, собственно из-за этого и ограничение — Вам нужно знать веса что бы попадать с первого раза на нужный мастер.
И в этом обычно нет проблем т.к. если разговор про Redis, то использовать один инстанс под всё, разграничивая номером БД это плохая практика.Softovick Автор
19.02.2018 14:06А вы используете где-то такой кластер Redis?
qRoC
19.02.2018 14:10Да, правда всего из 6 мастеров.
Softovick Автор
19.02.2018 14:24То есть все таки четное количество? Или это связано с объемом данных?
qRoC
19.02.2018 15:45Да, чётное, количество подобрано исходя из данных которые лежат в редисе.
Неважно кратное 3-м количество нод, 10, 100, или даже 2, к сожалению это влияет лишь на шанс падения всего кластера.Softovick Автор
19.02.2018 15:48Ну да, упадет один из мастеров и весь кластер недоступен… Это также работает и при большем, чем 3 мастера, количестве узлов?
qRoC
19.02.2018 16:17При падении 1 мастера кластер упасть не должен. Другое дело если падает два — тогда в случае 3 мастеров не получится организовать кворум для выбора слейвов(сами слейвы не могут голосовать), и поднимать нужно ручками. Больше нод — меньше шанс падения кластера.
Desprit
19.02.2018 13:24Еще одна хорошая БД прошла мимо статьи — RethinkDB, а у нее 20К звезд на GitHub.
Softovick Автор
19.02.2018 13:45Да, хорошая. Но меня лично напрягла ситуация с ее закрытием в конце 2016 года. Потом ее выкупили и снова начали поддерживать в начале 2017… Но у меня осадочек остался.
Desprit
19.02.2018 14:02По большому счету, это не так страшно. Даже после ее «закрытия» выкатывались новые минорные версии с небольшими фиксами. Надеюсь, что дальше будет как раньше :)
У нее просто потрясающий reql, ради него одного стоит хотя бы просто ознакомиться и потестить БД в небольших проектах, а там уж как пойдет.
ZeStas
19.02.2018 15:13MongoDB для вас, если:
— у вас нет четкой, заранее описанной структуры данных или вы предполагаете, что состав данных может потом сильно изменится (конечно это можно делать в SQL, но надо мыслить другими понятиями, поменять то можно, но вопрос насколько это будет трудоемко);
Плохой совет. Если у вас нет четко описанной структуры данных и вы не очень представляете, во что все это может превратиться в итоге, от использования NoSQL решений лучше воздержаться. Это более специализированный инструмент чем реляционные базы и применять его надо с умом, учитывая ограничения и хорошо представляя что и для чего делаете.
Пример во что может вылиться выбор NoSQL решения — Почему вы никогда не должны использовать MongoDBSoftovick Автор
19.02.2018 15:26Ну не считая того, что та статья 2013 года… Говорится там примерно о том же самом :) Или нет?
ZeStas
19.02.2018 16:28+1По-моему там говорится как раз об обратном. Здесь посыл — «не знаешь, какая будет структура у базы данных — используй MongoDB». В той статье приводится кейс, когда люди выбрали MongoDB, у них поменялась схема, в результате пришлось убить уйму человекочасов, что бы переписать все на реляционную базу.
Так что совет, на мой взгляд должен звучать так — «выбирайте MongoDB, если у вас есть четкая схема данных, хорошо ложащаяся на данную СУБД и есть уверенность что в будущем эта схема таковой и останется.»
Если же у вы не знаете, какая у вас будет структура данных, то тут лучше смотреть на тот же PostgreSQL с возможностью работы с JSON.Softovick Автор
20.02.2018 13:33Есть один момент. В той статье описана ситуация с огромным количеством разнообразных связей между данными. А не потому, что структура нечеткая была. Ну то есть, я не зря уточнил в минусах, что связности нет.
В тоже время в той статье именно так и пишется, что MongoDB идеальна для неструктурированной информации.
unitto1
19.02.2018 15:23Жаль что нет даже упоминания об NewSQL решениях. Например CockroachDB & OrientDB.
Softovick Автор
19.02.2018 15:23Хорошее уточнение. А что вы можете о них рассказать?
unitto1
19.02.2018 16:59+1Честно говоря полевого опыта применения у меня пока нет, сейчас осваиваю таракана на пет проекте.
По тому что увидел в данный момент — OrientDB не имеет ODM (object document mapper) для пайтона (в офф. доке есть инфа только о драйвере и OGM — object graph mapper), потому освоение ее я пока отложил. А вот CockroachDB мне показался более приемлемым — у него прозрачное маштабирование и хорошая выживаемость кластера (N-1 / 2)%, плюс он предоставляет наружный интерфейс для PostgreSQL (практически все остальные NewSQL базы — предоставляют интерфейс от MySQL). Есть небольшие различия в деалектах, но для большинства языков разработчики уже предоставили либы для наиболее распространенной ORM с новым диалектом. Плюс естественно есть драйвера популярных языков.
JekaMas
19.02.2018 15:26+1Softovick Про Aerospike я бы мог добавить минусы, доводилось с ней работать и сертифицироваться: Enterprise версия догорая, а Community постепенно была урезана до того, что в кластере можно иметь не более 3х нод и есть ограницение на объем данных и нет возможности применять какие-либо изменения настроек кластера без его полной перезагрузки, включая добавление новой «базы» (в понятиях Aerospike это «namespace»).
Так что минусы достаточно значительны.Softovick Автор
19.02.2018 15:28Спасибо… А что за ограничение на объем данных, какого порядка?
JekaMas
19.02.2018 15:39Нашел подробности, ограничение не в объеме данных, а в consistensy. Так называемая «strong consistency» убрана из Community и будет жить только в Enterprise.
aPiks
19.02.2018 16:49-2IBM Lotus Domino/Notes — это клиент почтовый и офисное ПО, а не СУБД.
Softovick Автор
19.02.2018 17:11+2Я вас удивлю, но это не так. А если быть более точным, не совсем так. Если коротко, это инфраструктура, где есть и почтовый сервер, клиент и СУБД и сервер приложений и офисный пакет (он там был не всегда). Причем сервер приложений есть и в клиенте и в серверной части.
aPiks
19.02.2018 16:55И почему в статье не упоминается ORACLE БД?
Это одна из самых стабильных баз данных и одна из самых быстрых и масштабируемых.Softovick Автор
19.02.2018 17:17На мой взгляд, выбор системы, которая распространяется только на платной основе, должен быть аргументированным решением. Но по опыту чаще всего использование таких продуктов выглядит скорее выбором менеджмента или уже используемое ПО диктует свои условия — либо ты делаешь на этом, либо вообще не занимаешься проектом. И хоть обдаказывайся, что Oracle Database круче всех, а у заказчика инфраструктура на IBM Notes… Ну врядли. А теперь покажите мне небольшой проект, который способен выкупить лицензию на Oracle Database.
aPiks
19.02.2018 18:42-1А в статье где-то упоминается про то, что обзор будет только о БД и СУБД для нищих стартапов и фрилансеров?
С утверждением по поводу выбора менеджмента вообще не согласен. Чаще всего такого рода выбор стоит не перед менеджментом, а перед техническими лидерами компании. Они предлагают техническое решение для менеджеров и его стоимость, а менеджмент решает, могут ли они потратить на это такую сумму. По опыту, БД с хорошей поддержкой, стабильностью и развитым инструментарием, впоследствии экономит немало средств на отсутствии простоев и издержек. Если правильно преподнести это для менеджера — они не будут спорить. А когда тут недавно появилась статья, о том, что яндекс переехал на Постедж потому что Оракл дорогой — ну это просто смешно. Особенно, когда они вкладывают деньги в мертворожденные проекты, но при этом экономят на основах.
ggo
20.02.2018 10:13Лучше бы структурировали по характистикам:
— с поддержкой честного ACID, и без оного
— с поддержкой in-memory, и без оного
— с поддержкой шардинга, и без оного
— структуры (реляционные, графы, key-value, timeseries)
— с поддержкой constraints во всех проявлениях, и без оного
— c поддержкой бизнес-логики во всех проявлениях внутри бд, и без оного
— наверно можно еще продолжить
Это только то, что интересно разработчику. И не касались инструментов.
А есть еще operation staff. Есть бизнеса…Softovick Автор
20.02.2018 13:30Цель статьи была в другом. Хотя хорошая идея, смутно представляю, как это реализовать в рамках сообщества Хабра :)
svetasmirnova
20.02.2018 11:08+1Статья сплошной facepalm. MySQL без настроек заточен под очень слабую машину. Как минимум innodb_buffer_pool_size и innodb_log_file_size нужно поменять. Судя по тому, что автор пользуется хостингом, скорее всего, хостинг провайдер и настроил MySQL, а PostgreSQL нет :)
Softovick Автор
20.02.2018 13:26Автор работает в хостинге, более 7 лет. И люди там работают, которые настройками и тюнингом занимались гораздо больше времени. Конечно при развитии проекта рано или поздно нужно настраивать и тюнинговать БД под реалии.
svetasmirnova
20.02.2018 13:39Зачем бред про работу на production из коробки пишете тогда?
Softovick Автор
20.02.2018 14:09Что именно вы считаете бредом, приведите пример.
svetasmirnova
20.02.2018 15:05Я же написала в предыдущем комментарии.
MySQL для вас, если:
— вы консерватор и не хотите вникать в настройки СУБД, просто поставили и работает (ну или на хостинге используете то, что дают);
Впрочем вот это объясняет:
— вы новичОк и вам нужна СУБД для управления структурными данными, желательно небольшими (до 1 — 2 гигабайт).
Для 1-2 гигабайт нечасто обновляемых данных можно и с настройками по умолчанию жить.Softovick Автор
20.02.2018 15:07А я ведь не зря написал в начале статьи отступления, в частности про тех у кого много данных или кто любит свою БД и умеет ее готовит… А так Вы правы, но статья моя не для этого задумывалась.
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.