Comments 11
Но если кратко, то это кластерное распределенное хранилище объектов по ключам, которое держит все данные в памяти, за счет чего достигается высокая скорость доступа к данным.
Было бы интересно увидеть сравнение с существующими подобными системами. Скажем, с MongoDB. Или есть ключевые отличия по функционалу?
Mongo хранит JSON (который является строкой), а грид хранит ваши объекты с учетом их типов.
Плюс к этому сам грид хранит данные только в памяти, запись их в постоянное хранилище (БД, файловая система и т.д.) можно настроить самостоятельно, но этим хранилища не являются частью кластера, а Mongo хранит всё на диске и сама решает, какие из имеющихся данных держать в памяти, то есть здесь разная концепция использования.
Правильнее рассматривать гриды как «умный кеш с возможностью обработки данных и записи их в БД», а не как «быстрая БД».
Плюс к этому сам грид хранит данные только в памяти, запись их в постоянное хранилище (БД, файловая система и т.д.) можно настроить самостоятельно, но этим хранилища не являются частью кластера, а 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.
А как у этого всего с транзакционностью и всяческим ACID?
Оказалось, что незалогиненным пользователям wiki страница была недоступна по умолчанию (даже если репозиторий открыт). Поправил это недоразумение
На момент вашей публикации в hazelcast уже была поддержка memcache протокола. С этим in-memory data grid можно работать из любого языка через memcache client
Да, вы правы. Причем такая возможность есть и в Infinispan, на котором и построен Sproot Grid, но:
Я думал над разными решениями тех задач, которые перед собой поставил, но ничего другое, кроме генерации кода, специфичного для конкретной доменной модели, не подходит под требования.
- API memcache беднее, чем у Sproot
- Та часть API, которую поддерживает Hazelcast и Infinispan, еще меньше
- Завязавшись на memcache я не смогу расширять API Sproot
- Memcache поддерживает только строковые ключи, а в Sproot я планирую реализовать поддержку ключей любого типа (хоть пользовательские объекты, хоть коллекции)
- Memcache практически не поддерживает пользовательские типы (он просто сериализует их в бинарники, забывая структуру, поэтому Hazelcast хранит не Java объекты, имеющие структуру объектов из доменной модели, а массивы байт)
- В следующей версии (выйдет этой зимой) Sproot сможет сам подгружать данные из базы, в случае отсутствия данных в кэше. Будет даже возможность собирать доменный объект по кусочкам из разных БД (или схем БД). Это невозможно без знания структуры объекта
- В планах есть и реализация возможности запуска распределенных задач на кластере, для чего опять же необходимо знать структуру объекта
Я думал над разными решениями тех задач, которые перед собой поставил, но ничего другое, кроме генерации кода, специфичного для конкретной доменной модели, не подходит под требования.
С сериализованными кешами в jvm проще работать, т.к. легко посчитать занимаемый (key,value) объем, хранить в off heap памяти.
В coherence есть экстракторы и предикаты, в hazelcast распределенные запросы
Для работы с разных языков можно сериализовать данные в thrift, protobuf, json, xml
Дело популяризации распределенных IMDG сейчас в тренде. Желаю вам привлечь веб разработчиков!
В coherence есть экстракторы и предикаты, в hazelcast распределенные запросы
Для работы с разных языков можно сериализовать данные в thrift, protobuf, json, xml
Дело популяризации распределенных IMDG сейчас в тренде. Желаю вам привлечь веб разработчиков!
Да, я понимаю, что можно работать с сериализованными данными, но надо знать их структуру, а memcache сериализует данные с потерей информации о структуре, поэтому для сериализации и транспорта использую thrift. В Infinispan всё уже естественно будет храниться в сериализованном инфиниспановском виде. В нём же есть и распределенные запросы.
Спасибо! Надеюсь, что получится.
Желаю вам привлечь веб разработчиков!
Спасибо! Надеюсь, что получится.
Sign up to leave a comment.
PHP + Java, или In-memory кластер теперь и для PHP разработчиков