DocumentDB: база данных NoSQL от Microsoft

[XaocCPS]

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

дополнительно, сегодня же был представлен еще один сервис, относящийся к работе с данными — Azure Search — облачный сервис индексирования данных

[PQR]

Автоматические индексы для всех данных — звучит слишком волшебно… должны быть и минусы у такого подхода, иначе, почему мы раньше всегда тщательно думали перед выбором полей для индексирования? Не пухнет ли от этого индекс и не замедляется ли вставка?

[XaocCPS]

Нужны независимые тесты. Сами разработчики пишут: «DocumentDB utilizes a highly concurrent, lock free, log structured indexing technology to automatically index all document content. This enables rich real-time queries without the need to specify schema hints, secondary indexes or views.»
azure.microsoft.com/en-us/documentation/articles/documentdb-introduction/

[voooz]

А тесты сравнения с конкурентами «произведений искусства программирования имени корпорации Майкрософт» уже можно публиковать? Или как и ранее нельзя?

[XaocCPS]

мне неизвестны никакие ограничения, более того постоянно встречаю сравнительные тесты на разные системы
вроде этого habrahabr.ru/company/microsoft/blog/221453/

[kekekeks]

в DocumentDB не нужно создавать индексы вообще. они создаются и используются автоматически для всех данных

А настраивать индексацию как в ElasticSearch можно? Эластик даёт возможность привязывать к каждому полю специально настраиваемый анализатор, например, оставляющий в индексе только словоформы.

[XaocCPS]

* хорошо бы еще пост в хаб «Microsoft Azure» добавить

[VikentiyR]

Поставляется ли (будет поставляться) DocumentDB отдельным решением для установки на сервер предприятия?
Если да, то будет DocumentDB частью MS SQL Server или отдельным продуктом?

[XaocCPS]

не поставляется. про будущее пока сказать нечего

[Nanako]

Будущее за PostgreSQL, Jsonb USING VODKA, вот это все.

[naum]

Водочный индекс убил наповал, очень крутое решение.

[int19h]

Это вы намекаете, что майкрософту надо купить Postgres? ;)

[Nanako]

Ну с Xamarin и Mono у них пока получается, так что почему бы и нет. Исходники .NET, например, меня очень порадовали, так что общее направление движения Microsoft мне нравится.

[dsx]

Хорошая попытка, Майкрософт, но поздно.

[zBit]

Ждём сравнительных тестов DocumentDB vs MongoDB vs PostgreSQL vs anything

[dsx]

Очень тяжело будет объективно сравнить, поскольку ни для MongoDB, ни для PostgreSQL MS Windows не является главной целевой платформой.

[Nanako]

Я, например, гоняю Постгрес на винде и вполне доволен. Могу, кстати, протестировать на реальном железе 9.4 на FreeBSD и Windows и сравнить производительность.

[zBit]

Было бы круто! Только нужно именно документо-ориентированные фишки тестить. Могу помочь с тестами, если нужно.

[Nanako]

Там боттлнек в разнице подхода к выделению процессов и потоков, непосредственно производительность движка почти одинаковая. В никсе по процессу на подключение — нормальное явление, а винда тяготеет к многопоточности, отдельные процессы — очень дорого. Для решения проблемы есть реализация пула процессов подключений, или можно заюзать persistent подключения от какой-нибудь ZeroMQ. При переносе логики с никсов на винду в лоб производительность резко падает из-за разницы в архитектурах.

[dsx]

Верю. Сам знаком с админами, которые в виду, скажем так, особенностей IIS предпочитают запускать на Windows Server Apache. Но это в первую очередь из-за особенностей IIS, а не из-за какой-то особенной волшебной произвозводительности Apache на Windows.

[zBit]

Что мешает использовать разные платформы?

[tangro]

Один юнит — это 10 ГБ места на SSD-диске, 2000 операций чтения в секунду, 500 операций в секунду вставки/замены/удаления, 1000 запросов в секунду к коллекции с возвращением одного документа.

Создаётся впечатление, что 1 юнит — это одновременно И «2000 операций чтения в секунду» И «500 операций в секунду вставки/замены/удаления» И «1000 запросов в секунду к коллекции с возвращением одного документа». По факту в оригинальной статье это всё — примеры того, как может быть использован один capacity unit. Т.е. на самом деле все «И» в предложении выше надо заменить на «ИЛИ».

[Bronx]

А разве 9.999 Гб, 1999 чтений/сек, 499 изменений/сек и 999 запросов/колл/док одновременно не будет нагрузкой всё ещё в рамках однго юнита? Это же ортогональные ограничения. Вот выход за ограничения — там да, получится правило «ИЛИ».

[tangro]

А разве 9.999 Гб, 1999 чтений/сек, 499 изменений/сек и 999 запросов/колл/док одновременно не будет нагрузкой всё ещё в рамках однго юнита?

Нет. Там используются некие условные единицы производительности, вот их хватает на 2000 операций чтения, или 500 операций замены\вставки, или 1000 запросов на поиск. Т.е. можно использовать, например, 1000 read и 250 write запросов — это ещё в пределах юнита.

[Bronx]

Странно, в калькуляторе они пишут: «Each unit of DocumentDB contains 10GB of high-performance disk storage and reserved throughput capacity.»

Если дело обстоит как вы говорите, то должны быть некие формулы обмена: сколько операций записи можно разменять на 1000 чтений, во сколько гигов мне всанут дополнительные 100 запросов И 100 операций чтения, и т.п. А если у меня 500 вставок в секунду, то что, размер базы должен быть равен нулю?

[tangro]

Если дело обстоит как вы говорите, то должны быть некие формулы обмена: сколько операций записи можно разменять

Так вот же. Там есть «стоимость» каждой операции, меняйте себе что хотите на что хотите (в плане операций обращения к базе, а общий размер — это отдельный, ортогональный параметр).

[Bronx]

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