Какая наиболее быстрая документоориентированная БД?

Question

[Александр Дегтярев]

Подскажите наиболее быструю и компактную БД для высоконагруженного сервиса, документоориентированную БД.
Если есть возможность, то встраиваемую

Comments

[Станислав Макаров]

Так вам встраиваемую или для высоконагруженного сервиса?
Какие требования по транзакциям/атомарности?

[Александр Дегтярев]

Станислав Макаров: для высоконагрузочного сервиса, очень частое обновление данных а равно и частые выборки из бд

[Станислав Макаров]

Александр Дегтярев какие выборки нужны? Нужны ли выборки внутри документа по разным критериям или может key-value достаточно и документно-ориентированная не нужна?

[Александр Дегтярев]

Станислав Макаров: слабосвязанные данные, например новости - краткое описание новостей точнее

Answer 1

[Станислав Макаров]

слабосвязанные данные, например новости - краткое описание новостей точнее

В общем, если нужны сложные выборки и несколько разных индексов - берите Монгу, если выборки только по одному ключу - посмотрите key-value: если вам для основного хранения (т.е. НЕ для кэша), то попробуйте Riak, если для кэширования чего-то, что уже и так есть в какой-то другой (основной) БД, то неплохо подойдет Redis.

Comments

[Александр Дегтярев]

Подскажите, NoSQL в целом по каким показателям проигрывают а по каким выигрывают SQL БД?

[Станислав Макаров]

Александр Дегтярев в целом говорить не совсем правильно, т.к. моделей данных и моделей хранения действительно разных очень много. Есть близкие к SQL, "почти-SQL", вроде Кассандры, а есть максимально простые хранилища вроде Redis. NoSQL базы обычно выигрывает по мастабируемости (т.к. СУБД проще и не такая гибкая как SQL-СУБД) - репликация настраивается проще и почти всегда из коробки, и простотой использования в простых сценариях, но проигрывают в гибкости (например, в документно-ориентированных базах обычно нет понятия, аналогичного JOIN в SQL) и иногда в надежности и атомарности/изоляции транзакций. Например, Монга гарантирует атомарность транзакции только в рамках документа. Это значит, что если вы просто не можете гарантированно записать два и более документов так, чтобы параллельные транзакции увидели сразу конечный результат. Это, в свою очередь, делает эту СУБД непригодной для финансовых транзакций.

Еще есть два фактора, которые зависят не сколько от самих NoSQL моделей данных, сколько от текущей ситуации: 1) многим SQL-базам уже не один десяток лет, и они набили много шишек, и вылечили "детские" болезни, с которыми можно столкнуться в более молодых СУБД; 2) NoSQL-решения, позволяющие работать с данными в отсутствие схемы иногда играют злую шутку с разработчиком, и отсутствие той дисциплины, которая нужна при проектировании SQL-базы приводит к превращению базы в кучу неуправляемого хлама.

В целом, главный критерий, который защитит вас от многих бед - выбирать базу либо исходя из жестких требований к производительности/масштабируемости, если таковые есть, либо исходя из модели данных вашего приложения. Есть данные, которые естественно укладываются в реляционную базу, есть данные, которые просятся в документную. Любимый мой пример: информация о товаре может быть разрознена и отличаться от товара к товару, поэтому обычно лучше её хранить в документной базе с необходимыми индексами. А вот информация о покупках обычно однотипная, т.к. указывается артикул или иной код товара, код клиента, количество. Или учет этих товаров на складе. Надежность и изоляция транзакций в этом случае будет очень важна, и мой выбор - реляционная СУБД.

[Станислав Макаров]

Александр Дегтярев и еще третий субъективный критерий: если вы пользовались до этого SQL-базами, обязательно внимательно читайте документацию и возможности той NoSQL-базы, которую вы выбрали. Многие из них внезапно могут не иметь тех свойств и гарантий, которые кажутся обязательными и само-собой разумеющимися в мире SQL. Это прямое следствие других подходов к архитектуре и других требований к СУБД. Есть проекты, где "быстро" важнее чем "точно" (см. eventual consistency).

[Александр Дегтярев]

Станислав Макаров: благодарю за ценные советы))