Кстати иногда годится еще такой вариант — вместо хэша использовать реверс ключа. Но это ок только если у последних байт равномернное распределение. В вашем примере получается такой ключ:
"iDremotsuc|year|month|day|transactionId"
И запрашивать 256 вариантов тогда не нужно.
Если верить тестам то Cassandra пошустрее, поэтому есть большой стимул попробовать её. С другой стороны в терминах CAP она AP (в отличие от HBase который CP) и что во многих случаях может быть неприемлемо.
Если я правильно понял, имеется в виду сделать размер хэша к примеру 1 байт и слать запрос сразу по всем 256 вариантам настроив фильтры вида:
Filter rowFilter=new RowFilter(CompareOp.EQUAL, new BinaryPrefixComparator(«hash|customerId|year|month»));
В принципе возможно, только это будет примерно в 100 раз медленнее работать чем, если запросить заранее известное количество ключей. Если запросов такого рода мало, то наверное имеет смысл. С другой стороны если запросы таковы, что покрывают значительную часть всего диапазона, то может быть эффективнее FullScan — собственно в одном из проектов мы так и делаем.
Если же понятно, что эта информация нужна для всех, то можно повесить сопроцессор на табличку и считать агрегаты по клиенту при записи в отдельной таблице с ключом «hash|customerId|year|month|day».
А вообще, конечно, работать с key-value БД не зная ключа довольно занимательная задача, у нас таких кейсов пока не было)
Рад что понравилось)
Если Вы имеете в виду, что набор интересующих ключей известен, то он просто заворачивается в List<Get> keys и отправляется командой: table.get(keys). Клиент получит адреса попавших в запрос регионов и разошлет им свои кусочки запросов. Получив ответы склеит и вернет Result[]
HBase используется по организационным причинам, в планах есть поработать с Cassandra и если результаты окажутся интересными то переедем на нее.
Zookeeper это кластер из 3-5 нод (где как)
Да, это не помогало. Backpressure уменьшает кол-во сообщений в батче, однако проблема была в том, что когда начинались тормоза он и маленький батч обрабатывал неприлично долго. Собственно выглядело так, что от размера батча время обработки мало зависела в этот момент.
А если серьезно, то с галочкой «оптимизировать код» такой запуск на результат практически не влияет. Ну и в реальной жизни крутить данные обычно приходится не выходя из среды. Так что это приближенный к реальным условиям случай, на мой взгляд.
В целом согласен, однако в данном конкретном случае была задача свериться с экселем (убедиться что все корректно рассчитано), а там логистической функции вроде нет. И конкретно на этих данных чтобы не расходилось шаг должен быть с десятком нулей после запятой и результат очень плохой, поэтому альтернативы нет)
Тут я имел в виду не столько цену hadoop решений самих по себе, сколько возможности обосновать исследовательские расходы. Если условный менеджер приходит и говорит:
«давайте построим хранилище Big Data и найдем там что-то полезное за X рублей»
ему могут их дать. А если он скажет:
«давайте построим хранилище и найдем там что-то полезное за X/5 рублей»
Ему с большей вероятностью откажут, хотя стоить будет дешевле и результат будет похожий. Но нет волшебных слов, так что увы)
Знать как делать селекты — полезно. Как скрещивать наборы — полезно. Человек с мозгами разберется как с этим работать. Если человек без мозгов, то читать это не будет. Лично мне бы такой пример сэкономил ровно три дня.
Кстати иногда годится еще такой вариант — вместо хэша использовать реверс ключа. Но это ок только если у последних байт равномернное распределение. В вашем примере получается такой ключ:
"iDremotsuc|year|month|day|transactionId"
И запрашивать 256 вариантов тогда не нужно.
Если верить тестам то Cassandra пошустрее, поэтому есть большой стимул попробовать её. С другой стороны в терминах CAP она AP (в отличие от HBase который CP) и что во многих случаях может быть неприемлемо.
Filter rowFilter=new RowFilter(CompareOp.EQUAL, new BinaryPrefixComparator(«hash|customerId|year|month»));
В принципе возможно, только это будет примерно в 100 раз медленнее работать чем, если запросить заранее известное количество ключей. Если запросов такого рода мало, то наверное имеет смысл. С другой стороны если запросы таковы, что покрывают значительную часть всего диапазона, то может быть эффективнее FullScan — собственно в одном из проектов мы так и делаем.
Если же понятно, что эта информация нужна для всех, то можно повесить сопроцессор на табличку и считать агрегаты по клиенту при записи в отдельной таблице с ключом «hash|customerId|year|month|day».
А вообще, конечно, работать с key-value БД не зная ключа довольно занимательная задача, у нас таких кейсов пока не было)
Если Вы имеете в виду, что набор интересующих ключей известен, то он просто заворачивается в List<Get> keys и отправляется командой: table.get(keys). Клиент получит адреса попавших в запрос регионов и разошлет им свои кусочки запросов. Получив ответы склеит и вернет Result[]
Zookeeper это кластер из 3-5 нод (где как)
«Если факты противоречат моей теории, тем хуже для фактов» (с)
А если серьезно, то с галочкой «оптимизировать код» такой запуск на результат практически не влияет. Ну и в реальной жизни крутить данные обычно приходится не выходя из среды. Так что это приближенный к реальным условиям случай, на мой взгляд.
«давайте построим хранилище Big Data и найдем там что-то полезное за X рублей»
ему могут их дать. А если он скажет:
«давайте построим хранилище и найдем там что-то полезное за X/5 рублей»
Ему с большей вероятностью откажут, хотя стоить будет дешевле и результат будет похожий. Но нет волшебных слов, так что увы)