Как стать автором
Обновить

Комментарии 11

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

Было бы интересно увидеть сравнение с существующими подобными системами. Скажем, с MongoDB. Или есть ключевые отличия по функционалу?
Mongo хранит JSON (который является строкой), а грид хранит ваши объекты с учетом их типов.
Плюс к этому сам грид хранит данные только в памяти, запись их в постоянное хранилище (БД, файловая система и т.д.) можно настроить самостоятельно, но этим хранилища не являются частью кластера, а Mongo хранит всё на диске и сама решает, какие из имеющихся данных держать в памяти, то есть здесь разная концепция использования.
Правильнее рассматривать гриды как «умный кеш с возможностью обработки данных и записи их в БД», а не как «быстрая БД».
Поправочка, MongoDB хранит в BSON данные.

Вот вырезка из офф. документации.
MongoDB stores documents on disk in the BSON serialization format. BSON is a binary representation of JSON documents, though it contains more data types than JSON.
Действительно, спасибо за поправку. Меня спутало то, что всё хранится в «JSON-style data structures».
А как у этого всего с транзакционностью и всяческим ACID?
На уровне java кластера транзакционность есть, но на уровень PHP я её еще не пробросил. Более того, как мне кажется без реализованного write-behind транзакционность не сильно нужна, поэтому подумаю над ней в следующем релизе, т.к., судя по результатам опроса, эта фича пока востребованнее всех.
Оказалось, что незалогиненным пользователям wiki страница была недоступна по умолчанию (даже если репозиторий открыт). Поправил это недоразумение
Да, вы правы. Причем такая возможность есть и в Infinispan, на котором и построен Sproot Grid, но:

  1. API memcache беднее, чем у Sproot
  2. Та часть API, которую поддерживает Hazelcast и Infinispan, еще меньше
  3. Завязавшись на memcache я не смогу расширять API Sproot
  4. Memcache поддерживает только строковые ключи, а в Sproot я планирую реализовать поддержку ключей любого типа (хоть пользовательские объекты, хоть коллекции)
  5. Memcache практически не поддерживает пользовательские типы (он просто сериализует их в бинарники, забывая структуру, поэтому Hazelcast хранит не Java объекты, имеющие структуру объектов из доменной модели, а массивы байт)
  6. В следующей версии (выйдет этой зимой) Sproot сможет сам подгружать данные из базы, в случае отсутствия данных в кэше. Будет даже возможность собирать доменный объект по кусочкам из разных БД (или схем БД). Это невозможно без знания структуры объекта
  7. В планах есть и реализация возможности запуска распределенных задач на кластере, для чего опять же необходимо знать структуру объекта

Я думал над разными решениями тех задач, которые перед собой поставил, но ничего другое, кроме генерации кода, специфичного для конкретной доменной модели, не подходит под требования.
С сериализованными кешами в jvm проще работать, т.к. легко посчитать занимаемый (key,value) объем, хранить в off heap памяти.
В coherence есть экстракторы и предикаты, в hazelcast распределенные запросы
Для работы с разных языков можно сериализовать данные в thrift, protobuf, json, xml

Дело популяризации распределенных IMDG сейчас в тренде. Желаю вам привлечь веб разработчиков!
Да, я понимаю, что можно работать с сериализованными данными, но надо знать их структуру, а memcache сериализует данные с потерей информации о структуре, поэтому для сериализации и транспорта использую thrift. В Infinispan всё уже естественно будет храниться в сериализованном инфиниспановском виде. В нём же есть и распределенные запросы.

Желаю вам привлечь веб разработчиков!

Спасибо! Надеюсь, что получится.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории