Шваров ЕвгенийИдея GlobalsDB в том, чтобы люди делали именно "промышленное", иначе зачем вообще играться. Подкупает в этом смысле успех MongoDB, реализовать аналог которого на GlobalsDB, похоже, довольно несложно. И в монге нет встроенного языка никакого, просто хранилище. Да еще и без транзакций. При этом монга в прошлом году заработала 75 млн. USD. На бесплатной СУБД)
А потом бы покупали Cache, DeepSee и Ensemble, конечно - возможно не в виде апгрейда GlobalsDB а для других проектов, где по бизнесу требуется другое качество информационной системы.
И драйверы покупки Cache' в этом случае это: горизонтальное масштабирование (ECP), OLAP (DeepSee), High Availability (Mirroring), интеграционные решения с Ensemble, ну и, разумеется, поддержка WRC.

Но тут мы можем поглядеть статистику, сколько успешных проектов на Cache использующих/неиспользующих COS. К гадалке можно не ходить, проектов без COS - меньше, хотя среди них есть такие звезды, как Гайа и биржевые проекты (Credit Suisse и проч). В СНГ тоже таких проектов сильно меньше, но есть. Т.е. как только люди узнают о возможностях COS с Cache, то, как правило, начинают его использовать. А Ensemble без COS вообще не бывает. Можно подискутировать о дальнейшем развитии COS и других серверных языках в Cache, но это тема отдельного разговора.
Насчет ограниченно-бесплатного Cache, менее ограниченного по крайней мере - согласен, замечания справедливые и разумные, возможно это будет когда-то.
Но зачем ждать - уже сейчас есть возможность, по крайней мере в СНГ, делать любой коммерческий стартап на полноценных Caché/Ensemble, на бесплатном хостинге и получить мораторий по оплате лицензии на год или "пока идея не выстрелит".

Евгений, насчет монго Вы в корне неправы. Вот на вскидку те причины, которые обеспечили популярность:
1. Работа с целыми документами, а не только key-value хранилище
2. Большие возможности по выборке/поиску документов, и кстати для этого используется V8
3. Знакомый синтаксис JavaScript для работы с базой
4. Большое число адаптеров для разных языков программирования и простота реализации нового адаптера
5. Мирроринг и шардинг из коробки в бесплатной версии
6. Нет ограничений на размер БД, использование памяти, процессоров и т.п..
7. Enterprise версия на сервер от 1500 до 7000 USD, не надо менять архитектуру разработки

По сравнению с Globals:
1. Этого нет. Да, можно реализовать, и я к примеру это могу сделать. Но не человек, который только знакомится с технологией. Это как простым автолюбителям вместо машины предлагать конструктор для ее сборки.
2. Только реализовывать ручками, что вкупе с отсутствием официальной поддержки COS довольно затруднительно. Плюс на элементарных операциях V8 быстрее COS VM, не так давно сравнивал.
3. Помолчим. И еще замечу нестабильность работы интерфейса node.js, раз в неделю-полторы его клинит.
4. PHP, Perl, Rubi где ?
5. Нет.
6. Не критично, но потенциально напрягает.
7. Тут можно только вздохнуть. Особенно для интернет проектов и с лицензированием на сервер.

Вот как раз за счет удобства, простоты, возможности сразу реализовать качественную архитектуру, а не функционально обрубленную, демократичной и понятной лицензионной политики монго и выигрывает. И особенно для новичков.

При этом совсем уж плохо о Globals я не хочу отзываться. На элементарных операциях система реально быстрее монго, зачастую выходит меньше кода и в некоторых случаях запускается там, где монго не стартует. А вот потенциальный переход на Cache, к примеру для реализации шардинга, где совсем простой лицензией не обойтись ... накладен шибко. Как говорится дизель хорош, ракеты пускает, а вот с удобством и интерьером как-то не очень.

DAiMorvisius1. Работа с целыми документами, а не только key-value хранилищеА можно поподробней с примерами про работу с целыми документами, я не совсем понимаю о чем это.


Под документом в данном случае подразумевается js объект, вроде такого:


т.е. структура данных, которая может быть достаточно большой и который мы оперируем в рамках одного обращения к СУБД. И для документа формируется схема и описываются правила, какие форматы данных (если нужно), индексация, связь между структурами. Mongo хоть и noSQL но отнюдь не shemaless.
И если в первичном описании схемы для поля указать к к примеру:


то автоматически получаем возможность быстрого поиска по этому полю документа.

И как мне кажется наличие такого функционала, где для индексации, выборки серии данных не нужно придумывать свои велосипеды, и одновременно нет обязательства строго следовать схеме (можно в любой момент записать экземпляр документа с отличными от других полями, лишь бы обязательные присутствовали). Так сказать готовый комплект для старта.
И равно это же свойство мешает высокой производительности монго на простых операциях, т.е. если я захочу хранить массив хэшей с минимальными реквизитами пользователей, Globals в разы быстрее монго.
А вот для сложных структур, если в монго я могу обойтись вызовом функции


и сразу получить набор нужных мне объектов, в Globals приходится самому городить выборку и фильтрацию, и главное обращаться для каждой операции к базе через небыстрый интерфейс.

DAiMorvisius3. Помолчим. И еще замечу нестабильность работы интерфейса node.js, раз в неделю-полторы его клинит.Ну Москва не сразу строилась, не так давно все это поддерживается, и у Mongo я думаю изначально были те кто развивал сначала это направление.
Я сильно на это надеюсь.

DAiMorvisiusPHP, Perl, Rubi где ? PHP и Perl точно есть, насчет Ruby не уверен.
У Cache - да, у Globals более скромный набор - Java, .NET, JavaScript.

DAiMorvisius2. Большие возможности по выборке/поиску документов, и кстати для этого используется V8visius2. Только реализовывать ручками, что вкупе с отсутствием официальной поддержки COS довольно затруднительно. Плюс на элементарных операциях V8 быстрее COS VM, не так давно сравнивал.Не совсем понятно причем тут COS, когда вы описываете проблемы GlobalsDB. V8 значит node.js, так в чем проблема ?

Я неявно объединил в одном пункте несколько свойств, и от этого похоже возникло недопонимание. На самом деле речь идет о встроенном языке платформы и тут я уже более перешел к сравнению Cache vs Mongo. И там и там для выборки нужно/можно писать внутренние процедуры. В первом случае мы имеем COS, во втором JavaScript - и для этого внутри монго используется V8. И по факту V8 быстрее. Для целочисленных переменных разница серьезная, для строк заметная. Детально не сравнивал - 3-4 алгоритма в цикле на секунды. Чисто Globals тут находится в полупроигрышном состоянии, т.к. для выборки данных в программах Cache и Mongo мы имеем непосредственный доступ к БД, то в связке Globals+node существуют затраты на вызов функций внешнего модуля, коим является Globals для node. И когда много таких элементарных обращений, они хорошо снижают производительность.

DAiMorно чтение документами, и индексы и поиск и все в этом духе решает грамотная ORM. которую разумеется можно самому написать и выдумать все самые удобные способы поиска, и для пользователя ORM не будет нужды больше как вы говорите городить сложную выборку.

visiusУ Cache - да, у Globals более скромный набор - Java, .NET, JavaScript.Не проверял, но думал, что частично поддержка этими драйверами от Cache есть и для GlobalsDB. Ну и GlobalsDB последняя версия была давно, и думаю от 2014 Cache подойдут эти драйверы.

тогда если быть уж до последнего честным, то тогда почему бы не вспомнить про объекты и sql в COS чего нет в MongoDB

Так с чего разговор начался - что сейчас MongoDB пользуется большой популярностью и за счет чего они завоевали такую популярность и умудрились 70 млн. заработать.

Руками ORM можно сделать, но для популярности базы такая ORM должна быть в комплекте.

В каше много чего есть, но не забываем, что "попробовать" бесплатно в продакшене каше нельзя.

К чему я в это обсуждение ввязался, - GlobalsDB, IMHO имеет право на существование, но в текущем виде ему не набрать популярности в силу внесенных ограничений и сложности прикручивания к потребностям среднестатистического интернет проекта. И очень сильно не хватает абстрактной GlobalsDB Enterprise, где было бы больше плюшек из каше, типа ECP и одновременно ценник на уровне +\- MongoDB.
Если еще года 2-3 в эту сторону не идти, то смысла существования GlobalsDB уже не вижу. Альтернативные проекты перейдут в стадию зрелости и ничего экстраординарного глобалы не дадут.

servitНа прошедшем мероприятии Global Summit 2013 была представлена презентация "Javascript: Not just a client-side language" , в которой помимо прочего упоминалось и о новой СУБД.
Приведу выдержку:


Да, примерно такой вариант и нужен сейчас на рынке. Остается вопрос с датой выхода, ценником и интенсивностью продвижения в умы.