История изменений

Работаю с обеими типами баз, в настоящий момент это MongoDB и Oracle. Не могу сказать, что из них лучше/хуже, по простой причине - задачи бывают разные. Вкратце сравнение:

1. Сеть. Oracle - шифрование и сжатие. MongoDB - ничего подобного нет. Не сказать, что это уж очень важный момент, но сжатие - рулит. Можно запихивать сжатые и шифрованные данные в монго - однако клиент от этого проще не станет.

2. Потребление памяти. Чем больше тем лучше, однако у монго зависимость от памяти пропорциональна объему хранимых данных. При этом выхода всего два - либо исправлять базу путем использования ключей в 1-2 символа и урезания объема данных, либо использовать шардинг.

3. ACID. Скажу кратко, в монго придется менять архитектуру клиента и/или свой взгляд на этот вопрос. Иногда это может быть сложно, неудобно или вообще невозможно и недопустимо. В простейших случаях допустить возможность появления устаревших данных, т.к. они не являются критичным случаем и не являются сбоем системы. Решение с введение коллекции с транзакциями лишь усложняет всю систему.

4. Гибкость построения сложных документов. Несмотря на то, что монго и другие NoSQL решения выдвигают чуть ли не главной фишкой создавать любые сложные документы - применение их в реальности сильно отличается. В частности, большие и сложные документы сказываются на а) удобстве их изменения, если необходимо делать какие-то проверки, то легче не станет: чем больше аргументов на проверки - тем больше придется делать индексов (некоторые индексы лучше вообще не строить без надобности), либо выкачивать целиком документы, что неразумно в ряде случаев; б) нагрузка на систему, перезапись документа ради одного поля в 5кб отличается от перезаписи другого документа менее чем в 100 байт. При этом, во втором случае всплывает вопрос об ACID, когда документ создается через ссылки из разных коллекций, баз и т.д. Увы, тем, кто сталкивался только с небольшими документами и не задавался вопросом об разбиении на поддокументы - видел лишь одну положительную сторону монго :) Выйдя на уровень сложных документов со ссылками, кроме вопроса по ACID, возникнет тот же вопрос как и в SQL - как связывать документики и вот тогда, монго снова покажет свою гибкость и удобство засчет возможности построения ссылок через массивы. Во-многих случаях этого будет достаточно, т.к. массивы в каждом документе будут весьма малы (менее 100) и по ним можно легко строить индексы, клиентская часть от этого не станет сложнее. Что в отличие от СУБД порой неудобно реализовать.

5. Третье-сторонние возможности. В то время, как pgsql, а oracle и тем ранее умеют выдавать данные в xml формате из коробки, этот вопрос полностью ложится на разработчика клиентской части mongo. Я не говорю, что это является обязательно фишкой любой БД, но в ряде задач это требуется. И тут монго, увы, проигрывает. Кроме XML, есть другие плюшки в виде инициации HTTP/TCP соединений непосредственно со стороны БД.

6. Масштабируемость. Коснусь только монго. Масштабируемость по чтению, легко делается через реплики с коеффициентом стоимости 1:1 (для увеличения на 100% требуется 1 сервер). Выйдя на уровень шардинга, т.е. когда ОЗУ станет просто не хватать или объемы данных превысят все возможные лимиты, коэффициент стоимости станет 1:2 (100% производительности ценой 2 серверов - 1 это новый сегмент и еще 1 - реплика для него). При этом, на высоконагруженных серверах бэкапирование данных с «горячих» серверов может стать просто критичным и невозможным, т.е. придется создавать реплику, с которой легко и быстро снимается бэкапы.

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

7. Итог. Прежде чем делать выбор SQL/NoSQL стоит взвесить все плюсы и минусы. NoSQL не избавит вас от проблем SQL, а даже наоборот добавит своих. Вопрос об ACID возможно остановит от выбора неправильного пути, а миф о том, что документы в монго принято хранить в виде одной записи с тысячью полей пусть так и останется мифом. А масштабируемость несмотря на свою прозрачность и простоту имеет свои недостатки. Сайтики на сто человек можно писать хоть с SQL, хоть без, выбор остается за тем, что ближе по складу ума - логичные и строгие таблицы, либо свобода действий, ограниченная фантазией :)

Работаю с обеими типами баз, в настоящий момент это MongoDB и Oracle. Не могу сказать, что из них лучше/хуже, по простой причине - задачи бывают разные. Вкратце сравнение:

1. Сеть. Oracle - шифрование и сжатие. MongoDB - ничего подобного нет. Не сказать, что это уж очень важный момент, но сжатие - рулит. Можно запихивать сжатые и шифрованные данные в монго - однако клиент от этого проще не станет.

2. Потребление памяти. Чем больше тем лучше, однако у монго зависимость от памяти пропорциональна объему хранимых данных. При этом выхода всего два - либо исправлять базу путем использования ключей в 1-2 символа и урезания объема данных, либо использовать шардинг.

3. ACID. Скажу кратко, в монго придется менять архитектуру клиента и/или свой взгляд на этот вопрос. Иногда это может быть сложно, неудобно или вообще невозможно и недопустимо. В простейших случаях допустить возможность появления устаревших данных, т.к. они не являются критичным случаем и не являются сбоем системы. Решение с введение коллекции с транзакциями лишь усложняет всю систему.

4. Гибкость построения сложных документов. Несмотря на то, что монго и другие NoSQL решения выдвигают чуть ли не главной фишкой создавать любые сложные документы - применение их в реальности сильно отличается. В частности, большие и сложные документы сказываются на а) удобстве их изменения, если необходимо делать какие-то проверки, то легче не станет: чем больше аргументов на проверки - тем больше придется делать индексов (некоторые индексы лучше вообще не строить без надобности), либо выкачивать целиком документы, что неразумно в ряде случаев; б) нагрузка на систему, перезапись документа ради одного поля в 5кб отличается от перезаписи другого документа менее чем в 100 байт. При этом, во втором случае всплывает вопрос об ACID, когда документ создается через ссылки из разных коллекций, баз и т.д. Увы, тем, кто сталкивался только с небольшими документами и не задавался вопросом об разбиении на поддокументы - видел лишь одну положительную сторону монго :) Выйдя на уровень сложных документов со ссылками, кроме вопроса по ACID, возникнет тот же вопрос как и в SQL - как связывать документики и вот тогда, монго снова покажет свою гибкость и удобство засчет возможности построения ссылок через массивы. Во-многих случаях этого будет достаточно, т.к. массивы в каждом документе будут весьма малы (менее 100) и по ним можно легко строить индексы, клиентская часть от этого не станет сложнее. Что в отличие от СУБД порой неудобно реализовать.

5. Третье-сторонние возможности. В то время, как pgsql, а oracle и тем ранее умеют выдавать данные в xml формате из коробки, этот вопрос полностью ложится на разработчика клиентской части mongo. Я не говорю, что это является обязательно фишкой любой БД, но в ряде задач это требуется. И тут монго, увы, проигрывает. Кроме XML, есть другие плюшки в виде инициации HTTP/TCP соединений непосредственно со стороны БД.

6. Масштабируемость. Коснусь только монго. Масштабируемость по чтению, легко делается через реплики с коеффициентом стоимости 1:1 (для увеличения на 100% требуется 1 сервер). Выйдя на уровень шардинга, т.е. когда ОЗУ станет просто не хватать или объемы данных превысят все возможные лимиты, коэффициент стоимости станет 1:2 (100% производительности ценой 2 серверов - 1 это новый сегмент и еще 1 - реплика для него). При этом, на высоконагруженных серверах бэкапирование данных с «горячих» серверов может стать просто критичным и невозможным, т.е. придется создавать реплику, с которой легко и быстро снимается бэкапы.

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

7. Итог. Прежде чем делать выбор SQL/NoSQL стоит взвесить все плюсы и минусы. NoSQL не избавит вас от проблем SQL, а даже наоборот добавит своих. Вопрос об ACID возможно остановит от выбора неправильного пути, а миф о том, что документы в монго принято хранить в виде одной записи с тысячью полей пусть так и останется для мифом. А масштабируемость несмотря на свою прозрачность и простоту имеет свои недостатки. Сайтики на сто человек можно писать хоть с SQL, хоть без, выбор остается за тем, что ближе по складу ума - логичные и строгие таблицы, либо свобода действий, ограниченная фантизией :)