NoSQL СУБД для веб-сервера на VDS

Question

[Владимир Чернышев]

Навеяно ответами к этому вопросу. Оказывается для MongoDB крайне желательно выделять отдельный сервер, т. к. память он отдавать не желает., что может быть чревато для других приложений.

В связи с этим вопрос — какую СУБД лучше поставить, чтобы её аппетиты до памяти можно было ограничивать. Желательно максимально близкую к Mongo, то есть свободная схема объектов/документов, но с разделением их на коллекции.

Спасибо.

Upd.: OS — Debian 6.0, nginx+php-fpm+passenger+mysql

Answer 1

[RuJet]

CouchDB

Answer 2

[TimTowdy]

Кроме вышеупомянутого кауча, вряд ли можно посоветовать что-то еще, готовое для продашкена, и работающее на VDS.
Вообще польза от NoSQL на VDS весьма сомнительна. NoSQL востребован там, где необходима неограниченная горизонтальная масштабируемость. Если такой потребности нет — MySQL/Postgres прекрасно подойдут практически для любой задачи. Не стоит гнаться за модными buzzwords, каждой задаче — свой инструмент.

Comments

[Владимир Чернышев]

Мне очень понравилось работать с БД без схемы (для некоторых задач). На РСУБД для таких задач приходится или вводить таблицы с атрибутами, или мастерить таблицы со 100500 полями, с используемыми в одной записи десятком максимум.

[VBart]

«Вообще польза от NoSQL на VDS весьма сомнительна. NoSQL востребован там, где необходима неограниченная горизонтальная масштабируемость.»
Вы ошибаетесь. Многие NoSQL решения это не только простота масштабирования, но и банально простата и удобство разработки. Документная модель базы зачастую гораздо точнее и лучше вписывается в нужды веб-сайтов\веб-приложений.

Answer 3

[andoriyu]

CouchDB и пока только CouchDB. Удивительно, что вас только расход памяти Mongo удивил, а то, что там нет понятие как целостность ноды и без реплекации вообще нет смысла выходить дальше девелопинга.

Answer 4

[Пума Тайланд]

Все таки в большинстве своем nosql решения ориентированы под безумную нагрузку и как бы вопроса о выносе на отдельный сервер или мало памяти там не стоит.
Может вам попробовать арендовать какой нибудь такой сервер?
ntel® Core™ i7-920 Quad-Core 4 физических ядра, 4 виртуальных (hyper-threading) 2 x 1500 GB HDD SATA2 (software RAID1) 24 GB DDR3
Установка 150 евро, аренда 89 в месяц
можно на нем нарезать квмом, опенвз, ксеном виртуалок и все закрутить.

Comments

[Владимир Чернышев]

Высокая скорость того же MongoDB для меня лишь бесплатный бонус к его внешним интерфейсам :) В принципе сейчас мы арендуем одно ядро из 8 очень похожего сервера за 1/7 его стоимости, наверное понятно, что не от хорошей жизни взяли одно ядро, а не 8 :(

[Пума Тайланд]

Суть там не в ядрах а в 24 гигах памяти.
То есть у вас вдс за 500 рублей?
Ну в большинстве и мускул довольно шустр, а про какие внешние интерфейсы вы говорите, монго сам не юзал, посмотрел на примеры использования в целом не увидел пока что особых преимуществ?

[Владимир Чернышев]

Угу, за 500, памяти тоже 1/8 (минус что-то забирает KVM, но можно пренебречь)

Под внешними интерфейсами я имел в виду схему БД, вернее её отсутствие :) Объекты («документы») в БД (условно «строки» в SQL) могут иметь произвольный набор атрибутов разных типов, в том числе сложных типа массивов, списков и других объектов. Фактически ORM (вернее ODM)заключается в JSON-сериализации/десериализации объектов модели (сложные типы данных разворачиваются), но в отличии от MySQL таблицы вида id->сериализованное значение, можно делать выборки и прочий CRUD по отдельным полям средствами БД, а не в приложении.

[Пума Тайланд]

Да суть в хороших выборках, только что углубленно проникся монгодибой.

Answer 5

[funca]

Читал, что в PostgreSQL есть продвинутые возможности для работы с XML — этот формат подходит для хранения документов с произвольной схемой. Можно делать выборки по xpath, строить индексы, и даже грабить… отдельные фрагменты документов. Может быть стоит поискать решение в этом направлении?