Реляционная БД тут при том, что IMDG может стоять перед этой БД. Если у вас есть серьезные причины, не позволяющие отказаться от реляционной базы, то вы можете просто выкачивать данные в IMDG и работать с ними там, при этом все изменения данных могут быть сохранены в БД для поддержания целостности данных.
Естественно, что модель данных для БД и для IMDG не будут совпадать, поэтому ваши Loader'ы будут обеспечивать преобразование данных из таблиц реляционной БД к вашей доменной модели.
1. Под распределенными вычислениями я подразумеваю MapReduce. Если разбирать на примере, то допустим у вас в кэше хранятся объекты, представляющие каких-то клиентов с их счетами, а вы хотите посчитать, сколько всего у них есть денег. Тогда вы на любом узле кластера отправляете запрос в кэш, этот запрос распространяется на все узлы, каждый узел подсчитывает свой результат и отправляет результат на тот узел, который инициировал запрос. А там результаты выполнения запросов с каждого узла складываются в один результат, который и возвращается.
2. Нет, это не особенность реализации. Это следствие того, что обращение к кэшам IMDG идет как к объектам вашего приложения (никаких удаленных вызовов вы не выполняете), т.е. вы кладете в IMDG ваши доменные объеты (Java-объекты, C#-объекты) без каких либо преобразований. Вы просто делаете cache.put(id, myJavaObject). Соответственно ORM, которые также оперируют с доменными объектами, могут использовать напрямую IMDG, и вам не придется хитро организовывать их взаимодействие. А если ORM будет брать данные не из БД, а из IMDG, то фактически IMDG будет являться кэшом этого ORM.
Также вы не сможете поставить Redis Cluster между вашим приложением и БД, потому что у него нет такого функционала (как я понял из презенации на их сайте). Если в Redis не оказалось требуемого объекта, то он вернет NULL, и вы не сможете сказать ему, чтоб он в этом случае сходил в БД, выполнил запрос, собрал из него доменный объект, выдал его вам и положил себе в хранилище.
3. Кэш — это key-value хранилище в памяти для объектов определенного типа. Т.е. когда вы конфигурируете и создаете кэш, то вы указываете какого типа будет ключ и какого типа будет значение, которое по этому ключу будет лежать.
А так как все операции записи будут идти в этот кэш (а дальше либо в БД, либо в веб-сервис, либо в файл, либо вам вообще не надо его сохранять вне памяти), то этот кэш всегда будет содержать только актуальные данные. Естественно, только в том случае, когда у вас нет приложений, которые работают в обход IMDG, потому что в этом случае данные в кэше и в БД могут различаться.
Базовые возможности и поверхностно рассказать о том, как реализовано, чтоб можно было составить представление, также было бы интересно посмотреть, как к ней прикручивается Hadoop. Давно хочу его попробовать, но постоянно не хватает времени, которое я себе выделяю на самообучение.
На основе этого можно было бы попробовать присобачить его к какому-нибудь гриду (не для практики, а интереса ради) и сравнить скорость нативного MR с Hadoop.
Про терракоту спорить не буду, вы лучше меня знаете, что она умеет. EhCache тоже не трогал руками, но если он также интегрирован в приложение, то ничего не мешает написать слушателя, который на каждый put будет выполнять сохранение данных куда-либо. Насчет падения скорости при дампе на диск — согласен, но туда можно сбрасывать данные, которые редко нужны либо просто в качестве бекапа на случай падения кластера.
Под обработкой данных я подразумеваю MR, который выполняется без десериализации данных, возможность переиндексирования данных при обновлении. Из коробки это есть (из известных мне) только в MongoDB, а в Redis, Membase, CouchDB поддержки MR нет, её надо прикручивать (возможно это и легко, спорить не буду).
Я тоже не говорю, что RDBMS + IMDG = SilverBullet :), и я согласен, что NoSQL решения богаты самыми востребованными функциями, но существуют ситуации, когда большие компании (а может и не очень большие) не могут отказаться от RDBMS в силу корпоративной архитектуры, где многие приложения являются потребителями (но не источниками) данных из БД.
Кстати IMDG может потреблять данные не только из БД, но и из веб-сервиса (что для NoSQL как мне кажется нелегко организовать).
Надеюсь, мы поняли друг друга в этом непростом вопросе, грозящем холиваром.
Когда мне ждать вашей статьи?:)
Грид — это тоже key-value, и он также состоит из шард (партиций). Никакого лишнего трафика между нодами кластера нет, т.к. если вы добавляете объект в кэш, то он быстро летит на ту ноду, куда ему определит алгоритм хэширования, плюс к этому, в зависимости от конфигурации, могут быть созданы резервные копии, которые будут размещены на других нодах кластера, причем сделано это будет асинхронно, так что никакого оверхеда по времени это не вызывает.
Конечно можно использовать грид в режиме репликации данных (т.е. каждая нода хранит полную копию данных, об этом я напишу в следующем посте), но этот режим не является часто используемым.
Прошу прощения, ответы на первые 2 вопроса куда-то подевались.
1. Если имеется несколько точек доступа к БД, то вы правы, но я рассматривал ситуацию, при которой есть только одно тяжелое приложение, которое хорошо нагружает БД, а IMDG стоит между базой и приложением. Тогда все запросы на чтение и запись идут не в БД, а в грид, поэтому там всегда содержатся актуальные данные. А грид уже в свою очередь может отправлять асинхронные запросы на запись в БД, либо накапливать объекты и потом записывать сразу пачкой и т.п. В этом случае нагрузка на базу минимальна, но и в базе и в кэше содержатся актуальные данные.
2. Не соглашусь с вами. IMDG — это скорее NoSQL + кластерный кэш + возможность обработки данных.
2.1. IMDG умеет писать в БД, файл или любое другое хранилище данных, таким образом тоже может обеспечивать долговременное хранение данных.
2.2. В посте я указывал, что возможны разные варианты загрузки данных в грид:
— с самого начала выкачать из постоянного хранилища (БД) необходимые данные
— ничего при старте не выкачивать (если память или время поджимают), а подтягивать данные во время выполнения запроса
Поэтому необязательно иметь количество памяти соответствующее объему данных.
Что я подразумеваю под «IMDG — это часть вашего приложения»:
Допустим, вы написали конфиг вашего кластера config.xml, после этого вы пишете класс наподобие такого public class MyClass {
private Map<KeyType, ValueType> myCache;
public void startCluster() {
IMDGConfig config = new IMDGConfig("config.xml");
CacheManager manager = new CacheManager(config);
myCache = manager.getCache("someName");
}
}
Всё, больше никаких движений совершать не нужно. После этого вы сможете спокойно класть объекты в myCache. Здесь это поле имеет тип Map, т.к. кэш реализует этот интерфейс, но вы вполне можете использовать тип Cache для получения дополнительных возможностей, но с точки зрения использования этот кэш всё равно останется всего лишь полем класса.
Более того, если вы запустите этот код на двух jvm, то они автоматически соединятся в кластер.
Что касается get/put/delete, то возможности IMDG этим не ограничиваются.
4. IMDG поддерживает распределенные транзакции, и например в Deutsche Bank активно используется Oracle Coherence. Правда я там не работал, и не могу утверждать, что он там используется именно для проведения финансовых транзакций, но исключать этого не могу, т.к. все возможности для этого есть.
P.S. А вы не писали статью на тему своего опыта работы с terracota? Если писали, то поделитесь пожалуйста ссылочкой, мне было бы интересно, а если нет, то считайте это официальным реквестом:)
1. Redis только готовятся выпустить свой кластер из коробки, тогда как Oracle купил компанию Tangosol (ради их продукта — Tangosol Coherence) аж в 2007 году. Т.е. надежность и отточенность этого продукта должна быть выше.
2. Кластер Redis — это только кластерное key-value хранилище, в то время как in-memory-data-grid подразумевает организацию распределенных вычислений на хранящихся данных, а также их обработку.
3. Redis не может быть кэшом 2 уровня (поправьте меня, если я не прав, ибо нет 100% уверенности) какого-нибудь ORM, а также не предназначен для того, чтоб стоять перед какой-нибудь реляционной БД и выполнять read-through/write-behind
4. Судя по презентации на их сайте, данные можно спросить только на той ноде, на которой они расположены. Если вы спросили не там, где надо — вернется ошибка и номер ноды, у которой надо спросить. Также можно написать (или он уже есть, я из презентации этого не понял) smart client, который будет сначала спрашивать карту кластера с распределением ключей по нодам, а потом спрашивать данные на нужной ноде.
В то время как в гриде вам абсолютно наплевать, в каком месте кластера лежат данные, потому что по запросу их доставят на ту ноду, откуда поступил запрос.
5. Многие действия с кластером надо производить вручную с помощью какой-то утилиты, что не позволяет надолго оставлять его без присмотра, а также требует участия админа в поддержании работоспособности и масштабирования кластера.
6. Запрос к Redis составляется на их внутреннем языке запросов, потому что NoSQL — это отдельное приложение, доступ к которому осуществляется снаружи. IMDG — это часть вашего приложения. А так как кэши реализуют интерфейс Map, то и обращаться с ними вы можете как с обычными объектами вашего приложения. Соответственно, если вам надо не просто достать объект по ключу, а сделать какой-либо запрос, то вы пишете его на Java (подставьте сюда любой другой язык, который поддерживается конкретным IMDG решением), что позволяет получить из хранилища сразу объекты вашей доменной модели и без необходимости трансформации.
7. В презентации ничего не написано про индексацию данных в кластере. Индекс распределенный или реплицированный? А может он хранится так же как и данные, в конкретном месте, и активное обращение к ноде с индексом будет создавать большую нагрузку?
В общем я вижу сильные различия в тех подходах, которые выбрали разработчики Redis Cluster и концепцией IMDG.
Индексы.
В некоторых IMDG (например Oracle Coherence), индексы распределены по узлам кластера, т.е. на каждом узле лежит кусочек индекса, который относится к данным на этом узле. Затем каждый запрос выполняется отдельно на каждом узле кластера, а результаты стекаются на тот узел, который инициировал запрос, там они и формируют конечный ответ. В некотором роде это Map Reduce.
В некоторых гридах индексирование данных выполняется с использованием open source поисковых движков. Примером служит JBoss Infinispan, в котором используется Apache Lucene. Там индекс хранится в RAM Directory. Вопрос индексирования более подробно рассмотрю в следующей статье, так как в комментарий не поместится.
Спасибо за вопрос, в следующей статье раскрою эту тему, а пока собираю вопросы, т.к. если написать всё сразу, то получится слишком большая статья, и никто её не будет читать, поэтому в вводной статье оставил только описание самой концепции.
А проблема concurrent modification в кластерах решается за счет механизма распределенных блокировок.
Естественно, что модель данных для БД и для IMDG не будут совпадать, поэтому ваши Loader'ы будут обеспечивать преобразование данных из таблиц реляционной БД к вашей доменной модели.
2. Нет, это не особенность реализации. Это следствие того, что обращение к кэшам IMDG идет как к объектам вашего приложения (никаких удаленных вызовов вы не выполняете), т.е. вы кладете в IMDG ваши доменные объеты (Java-объекты, C#-объекты) без каких либо преобразований. Вы просто делаете cache.put(id, myJavaObject). Соответственно ORM, которые также оперируют с доменными объектами, могут использовать напрямую IMDG, и вам не придется хитро организовывать их взаимодействие. А если ORM будет брать данные не из БД, а из IMDG, то фактически IMDG будет являться кэшом этого ORM.
Также вы не сможете поставить Redis Cluster между вашим приложением и БД, потому что у него нет такого функционала (как я понял из презенации на их сайте). Если в Redis не оказалось требуемого объекта, то он вернет NULL, и вы не сможете сказать ему, чтоб он в этом случае сходил в БД, выполнил запрос, собрал из него доменный объект, выдал его вам и положил себе в хранилище.
3. Кэш — это key-value хранилище в памяти для объектов определенного типа. Т.е. когда вы конфигурируете и создаете кэш, то вы указываете какого типа будет ключ и какого типа будет значение, которое по этому ключу будет лежать.
А так как все операции записи будут идти в этот кэш (а дальше либо в БД, либо в веб-сервис, либо в файл, либо вам вообще не надо его сохранять вне памяти), то этот кэш всегда будет содержать только актуальные данные. Естественно, только в том случае, когда у вас нет приложений, которые работают в обход IMDG, потому что в этом случае данные в кэше и в БД могут различаться.
На основе этого можно было бы попробовать присобачить его к какому-нибудь гриду (не для практики, а интереса ради) и сравнить скорость нативного MR с Hadoop.
Под обработкой данных я подразумеваю MR, который выполняется без десериализации данных, возможность переиндексирования данных при обновлении. Из коробки это есть (из известных мне) только в MongoDB, а в Redis, Membase, CouchDB поддержки MR нет, её надо прикручивать (возможно это и легко, спорить не буду).
Я тоже не говорю, что RDBMS + IMDG = SilverBullet :), и я согласен, что NoSQL решения богаты самыми востребованными функциями, но существуют ситуации, когда большие компании (а может и не очень большие) не могут отказаться от RDBMS в силу корпоративной архитектуры, где многие приложения являются потребителями (но не источниками) данных из БД.
Кстати IMDG может потреблять данные не только из БД, но и из веб-сервиса (что для NoSQL как мне кажется нелегко организовать).
Надеюсь, мы поняли друг друга в этом непростом вопросе, грозящем холиваром.
Когда мне ждать вашей статьи?:)
Конечно можно использовать грид в режиме репликации данных (т.е. каждая нода хранит полную копию данных, об этом я напишу в следующем посте), но этот режим не является часто используемым.
1. Если имеется несколько точек доступа к БД, то вы правы, но я рассматривал ситуацию, при которой есть только одно тяжелое приложение, которое хорошо нагружает БД, а IMDG стоит между базой и приложением. Тогда все запросы на чтение и запись идут не в БД, а в грид, поэтому там всегда содержатся актуальные данные. А грид уже в свою очередь может отправлять асинхронные запросы на запись в БД, либо накапливать объекты и потом записывать сразу пачкой и т.п. В этом случае нагрузка на базу минимальна, но и в базе и в кэше содержатся актуальные данные.
2. Не соглашусь с вами. IMDG — это скорее NoSQL + кластерный кэш + возможность обработки данных.
2.1. IMDG умеет писать в БД, файл или любое другое хранилище данных, таким образом тоже может обеспечивать долговременное хранение данных.
2.2. В посте я указывал, что возможны разные варианты загрузки данных в грид:
— с самого начала выкачать из постоянного хранилища (БД) необходимые данные
— ничего при старте не выкачивать (если память или время поджимают), а подтягивать данные во время выполнения запроса
Поэтому необязательно иметь количество памяти соответствующее объему данных.
Допустим, вы написали конфиг вашего кластера config.xml, после этого вы пишете класс наподобие такого
public class MyClass {
private Map<KeyType, ValueType> myCache;
public void startCluster() {
IMDGConfig config = new IMDGConfig("config.xml");
CacheManager manager = new CacheManager(config);
myCache = manager.getCache("someName");
}
}
Всё, больше никаких движений совершать не нужно. После этого вы сможете спокойно класть объекты в myCache. Здесь это поле имеет тип Map, т.к. кэш реализует этот интерфейс, но вы вполне можете использовать тип Cache для получения дополнительных возможностей, но с точки зрения использования этот кэш всё равно останется всего лишь полем класса.
Более того, если вы запустите этот код на двух jvm, то они автоматически соединятся в кластер.
Что касается get/put/delete, то возможности IMDG этим не ограничиваются.
4. IMDG поддерживает распределенные транзакции, и например в Deutsche Bank активно используется Oracle Coherence. Правда я там не работал, и не могу утверждать, что он там используется именно для проведения финансовых транзакций, но исключать этого не могу, т.к. все возможности для этого есть.
P.S. А вы не писали статью на тему своего опыта работы с terracota? Если писали, то поделитесь пожалуйста ссылочкой, мне было бы интересно, а если нет, то считайте это официальным реквестом:)
У вас нет предложений по конкретным NoSQL для тестов? MongoDB, Redis, CouchDB, Membase?
2. Кластер Redis — это только кластерное key-value хранилище, в то время как in-memory-data-grid подразумевает организацию распределенных вычислений на хранящихся данных, а также их обработку.
3. Redis не может быть кэшом 2 уровня (поправьте меня, если я не прав, ибо нет 100% уверенности) какого-нибудь ORM, а также не предназначен для того, чтоб стоять перед какой-нибудь реляционной БД и выполнять read-through/write-behind
4. Судя по презентации на их сайте, данные можно спросить только на той ноде, на которой они расположены. Если вы спросили не там, где надо — вернется ошибка и номер ноды, у которой надо спросить. Также можно написать (или он уже есть, я из презентации этого не понял) smart client, который будет сначала спрашивать карту кластера с распределением ключей по нодам, а потом спрашивать данные на нужной ноде.
В то время как в гриде вам абсолютно наплевать, в каком месте кластера лежат данные, потому что по запросу их доставят на ту ноду, откуда поступил запрос.
5. Многие действия с кластером надо производить вручную с помощью какой-то утилиты, что не позволяет надолго оставлять его без присмотра, а также требует участия админа в поддержании работоспособности и масштабирования кластера.
6. Запрос к Redis составляется на их внутреннем языке запросов, потому что NoSQL — это отдельное приложение, доступ к которому осуществляется снаружи. IMDG — это часть вашего приложения. А так как кэши реализуют интерфейс Map, то и обращаться с ними вы можете как с обычными объектами вашего приложения. Соответственно, если вам надо не просто достать объект по ключу, а сделать какой-либо запрос, то вы пишете его на Java (подставьте сюда любой другой язык, который поддерживается конкретным IMDG решением), что позволяет получить из хранилища сразу объекты вашей доменной модели и без необходимости трансформации.
7. В презентации ничего не написано про индексацию данных в кластере. Индекс распределенный или реплицированный? А может он хранится так же как и данные, в конкретном месте, и активное обращение к ноде с индексом будет создавать большую нагрузку?
В общем я вижу сильные различия в тех подходах, которые выбрали разработчики Redis Cluster и концепцией IMDG.
В некоторых IMDG (например Oracle Coherence), индексы распределены по узлам кластера, т.е. на каждом узле лежит кусочек индекса, который относится к данным на этом узле. Затем каждый запрос выполняется отдельно на каждом узле кластера, а результаты стекаются на тот узел, который инициировал запрос, там они и формируют конечный ответ. В некотором роде это Map Reduce.
В некоторых гридах индексирование данных выполняется с использованием open source поисковых движков. Примером служит JBoss Infinispan, в котором используется Apache Lucene. Там индекс хранится в RAM Directory. Вопрос индексирования более подробно рассмотрю в следующей статье, так как в комментарий не поместится.
Да, я планирую написать еще как минимум 2 поста. Надеюсь уложиться до конца августа.
А проблема concurrent modification в кластерах решается за счет механизма распределенных блокировок.
Простите, а что такое CME?