Info: лицензия за GemFire на 1 нод на один год - 25K$. Т.е. кластер на 40 нодов - 1M$/year.
1.000.000$ с КАЖДОГО бизнеса КАЖДЫЙ год пользования твоим IMDG!
Так это еще и низкая цена - Oracle Coherence стоит заметно дороже.
P.S. Да к черту эти стартапы! Социальные сети для собак, e-shops, новейшие сервисы по отсылу СМС, ... Все на написание IMDG!
суббота, 19 февраля 2011 г.
Подписаться на:
Комментарии к сообщению (Atom)
jboss infinispan чем плох ?
ОтветитьУдалитьвообще не очень в теме, какие задачи решает IMDG?
это разве не обычный кеш + транзакции?
>>jboss infinispan чем плох ?
ОтветитьУдалитьНе знаю, не использовал.
>>вообще не очень в теме, какие задачи решает IMDG? это разве не обычный кеш + транзакции?
Ну тут сложности с тем, что такое обычный кэш.
1) с точки зрения API к обычному кэшу (Map API) добавляется (на примере Oracle Coherence[http://download.oracle.com/otn_hosted_doc/coherence/350/com/tangosol/net/NamedCache.html]):
- InvocableMap
- ObservableMap
- QueryMap
2) с точки зрения функционала:
- возможность добавлять индексы, включая вторичные
- возможность делать view на основе Continious Query
- возможность делать распределенные по нодам запросы поиска/агрегирования
- есть ли и какие примитивы распределенной синхронизации
3) с точки зрения архитектуры:
- возможность конструировать кэш как слоеный пирог из "примитивных" кэшей
- гибкие возможности работы для multisite replication (когда consistency внутри датацентра строже чем между датацентрами)
4) с "исследовательской" точки зрения:
- CAP-теорема очерчивает границу допустимого для распределенного приложения, вопрос в том - как близко данная реализация подходит к этой границе, в какой точке, и можем ли мы гибко управлять чем жертвовать из тройки C/A/P
- максимально сложный сбой, при котором клиенты этого не заметят (веерная перезагрузка серверов, резкое падение пропускной способности каналов связи между датацентрами, потеря пакетов определенного типа, и т.д.)
Ещё один вопрос - зачем вообще нужен IMDG?
ОтветитьУдалитьКак я понимаю IMDG ставиться между базой данных и приложением. Для кеширования данных в памяти, то есть он может спасти при операциях чтения закешированных данных. Но при операциях записи он никак не влияет.
Вывод: IMDG - может уменьшить нагрузку на базу данных при чтении закешированных данных. Для записи он бесполезен.
Также может использовать память многих компьютеров если у нас база на одном компьютере.
Но когда у нас есть распределённая база данных (Google Big Table), то там сама база может легко кешировать данные в памяти на 1000 компьютеров. Хотя конечно подсистема кеширования в базе данных может частично или полностью пересекаться с IMDG.
Так что мой призыв: нужно писать базу данных :))
всё таки haddop и casandra - это маловато для мира )
Насчёт CAP у меня странное чувство вот когда читаешь всё выглядит хорошо, а вот когда дело доходит до практических примеров, то кажется что CAP не нужна.
Здесь наткнулся на некоторые статьи про CAP
http://citforum.ru/gazeta/154
http://citforum.ru/gazeta/169
>>Ещё один вопрос - зачем вообще нужен IMDG?
ОтветитьУдалить>>Как я понимаю IMDG ставиться между базой данных и приложением.
--
Как я понимаю, IMDG предлагают использовать, в том числе, не в качестве слоя между AppLayer и StorageLevel в трехуровневой архитектуре (т.е. вроде кэша второго уровня для Hibernate - тут подходят и более слабые решения, как EHCache), а в качестве "приемника" данных от множества высокопроизводительных источников. Над этими данными производятся средствами IMDG некоторые действия и результаты могут сохранятся в базу или передаваться дальше (скажем по JMS).
Пример: потоки данных от многих бирж в которых в реальном времени необходимо отслеживать какую-активность активность.
Рискну утверждать, что IMDG хороши для Streaming apps, в том смысле как их описывает Stonebreaker (http://www.cs.brown.edu/~ugur/fits_all.pdf - в статье он говорит про эксперимент, в котором RDBMS обрабатывало 900tps, а специализированное решение - 160.000tps).
Некоторые IMDG в принципе "переросшие" Linda-системы (как Gigaspaces XAP), т.е. идеальны для реализации Masters/Workers.
К слову, Gigaspaces XAP хвалятся, что используя их API есть реализация полноценного JMS.
Из статьи Stonebreaker мне очень понравилась идеология разделения на "Inbound" versus "Outbound" processing.
>>Для кеширования данных в
памяти, то есть он может спасти при операциях чтения закешированных данных. Но при операциях записи он никак не влияет.
--
При политике записи Write-Through - да, запись в backing store (если оно есть) идет синхронно, но при политике Write-Behind данные будут асинхронно сброшены в хранилище.
Авторы называют свойство данных сохранятся в рамках RAM всего кластера - Cluster-Aware. Эдакая ослабленная версия Durability.
>>Вывод: IMDG - может уменьшить нагрузку на базу данных при чтении закешированных данных. Для записи он бесполезен.
Также может использовать память многих компьютеров если у нас база на одном компьютере.
>>>>Но когда у нас есть распределённая база данных (Google Big Table), то там сама база может легко кешировать данные в памяти на 1000 компьютеров. Хотя конечно подсистема кеширования в базе данных может частично или полностью пересекаться с IMDG.
GFS/BigTable/MapReduce, как я понимаю, по своим архитектурным решениям не может обеспечить low latency. Т.е. речь о 100-1000 mcsec не идет в принципе.
Так что мой призыв: нужно писать базу данных :))
всё таки haddop и casandra - это маловато для мира )
>>Насчёт CAP у меня странное чувство вот когда читаешь всё выглядит хорошо, а вот когда дело доходит до практических примеров, то кажется что CAP не нужна.
Здесь наткнулся на некоторые статьи про CAP
http://citforum.ru/gazeta/154
http://citforum.ru/gazeta/169
--
Честно говоря, у меня нет такого объемлющего опыта как у Stonebreaker, что бы апеллировать к нему:)
Но вот Werner Vogels (CTO - Amazon.com) использует Eventually Consistency - http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html. Как я понимаю, тут под Partition Tolerance можно подразумевать не реальное партицирование сети, а отсутствие откликов от некоторых нод в рамках обработки запроса в течении допустимого latency (скажем 25мс).
За статьи - спасибо. Возможно позже отпишусь детальнее.
с чем то согласен )
ОтветитьУдалитьну в принципе логика достаточно проста.
Мы обновляем какие то данные часто, что бы снизить нагрузку на винт мы записываем не каждое обновление , а например раз секунду. Но что будет если сбой . Тогда мы дублируем данные на нескольких компьютерах в памяти.
Конечно нужно смотреть что мы теряем при дублировании, но в принципе этот вариант рабочий. Если банки согласны ).
Плюсы IMDG по сравнению с базами данных.
1) быстрые апдейты
2) тригеры-колбеки (они кому-нибудь нужны :) )
C тем что IMDG будут востребованны нельзя не согласиться.
Вообще конечно думаю основной вопрос, насколько маштабируемы базы данных. После ответа можно делать и IMDB и hbase. ИМХО
ОтветитьУдалитьЗа статьи спасибо.
Кстати я до сих пор не понял есть ли в hbase serializable транзакции. В cassandra как я понял их нет. Видел статью где в cassandra предлагают использовать zookeeper, но zookeeper как я понял это локи а не транзакции.
А вот в GAE в доках http://code.google.com/intl/en/appengine/docs/java/datastore/transactions.html написано что есть SERIALIZABLE
у Infinispan раньше читал нет SERIALIZABLE (щас не могу найти)