Исправление
vertexua,
(текущая версия)
:
Ну как сказать, это клон BigTable. А ее вообще выдрали из интигрированой инфраструктуры в единственном екземпляре. Опять же, для разработки в HBase все в полпинка подымается. Для говносайтиков конечно прийдется подымать жирный продакшн, но зачем HBase для говносайтиков
тормоза
Представь краулер. Просто неимоверное количество данных индексируется. Не важно как быстро ляжет в базу (в разумных пределах), но важно чтобы БД это проглотила. Нужна консистентность на некоторых задачах. Нужен column-family без вариантов. И да, нужно сканирование ренжей rowkey иногда. Нужен MapReduce. Выборка все равно не стучит прямо в HBase, все на кешах. Ну вот и смотри, тормоза это или нет
Собственно когда бенчмаркали последний раз, то Riak и MySQL Cluster быстро копытца откинули. Только HBase и Cassandra линейно масштабировались. Не помню что там с лейтенси, собственно за что некоторые ругают HBase, но общий throughput был на высоте и не оставал от кассандры
Исправление
vertexua,
:
Ну как сказать, это клон BigTable. А ее вообще выдрали из интигрированой инфраструктуры в единственном екземпляре. Опять же, для разработки в HBase все в полпинка подымается. Для говносайтиков конечно прийдется подымать жирный продакшн, но зачем HBase для говносайтиков
тормоза
Представь краулер. Просто неимоверное количество данных индексируется. Не важно как быстро ляжет в базу (в разумных пределах), но важно чтобы БД это проглотила. Нужна консистентность на некоторых задачах. Нужен column-family без вариантов. И да, нужно сканирование ренжей rowkey иногда. Нужен MapReduce. Выборка все равно не стучит прямо в HBase, все на кешах. Ну вот и смотри, тормоза это или нет
Собственно когда бенчмаркали последний раз, то Riak и MySQL Cluster быстро копытца откинули. Только HBase и Cassandra линейно масштабировались
Исправление
vertexua,
:
Ну как сказать, это клон BigTable. А ее вообще выдрали из интигрированой инфраструктуры в единственном екземпляре. Опять же, для разработки в HBase все в полпинка подымается. Для говносайтиков конечно прийдется подымать жирный продакшн, но зачем HBase для говносайтиков
тормоза
Представь краулер. Просто неимоверное количество данных индексируется. Не важно как быстро ляжет в базу (в разумных пределах), но важно чтобы БД это проглотила. Нужна консистентность на некоторых задачах. Нужен column-family без вариантов. И да, нужно сканирование ренжей rowkey иногда. Нужен MapReduce. Выборка все равно не стучит прямо в HBase, все на кешах. Ну вот и смотри, тормоза это или нет
Исправление
vertexua,
:
Ну как сказать, это клон BigTable. А ее вообще выдрали из интигрированой инфраструктуры в единственном екземпляре. Опять же, для разработки в HBase все в полпинка подымается.
тормоза
Представь краулер. Просто неимоверное количество данных индексируется. Не важно как быстро ляжет в базу (в разумных пределах), но важно чтобы БД это проглотила. Нужна консистентность на некоторых задачах. Нужен column-family без вариантов. И да, нужно сканирование ренжей rowkey иногда. Нужен MapReduce. Выборка все равно не стучит прямо в HBase, все на кешах. Ну вот и смотри, тормоза это или нет
Исходная версия
vertexua,
:
Ну как сказать, это клон BigTable. А ее вообще выдрали из интигрированой инфраструктуры в единственном екземпляре.
тормоза
Представь краулер. Просто неимоверное количество данных индексируется. Не важно как быстро ляжет в базу (в разумных пределах), но важно чтобы БД это проглотила. Нужна консистентность на некоторых задачах. Нужен column-family без вариантов. И да, нужно сканирование ренжей rowkey иногда. Нужен MapReduce. Выборка все равно не стучит прямо в HBase, все на кешах. Ну вот и смотри, тормоза это или нет