key-value storage с объемом порядка 50-100 терабайт

Яндекс- гугло- дропо- диск. Только придется индусам за декапчу заплатить.

Хм, а где почитать про капчу и лимит запросов дропбокса? Вот куплю я у них подписку за $750 в год, и буду через апи создавать/читать миллиард файлов по 10 килобайт (пишут же, что объем без ограничений)? Или что-то этому все же помешает?

redis, consistent hashing для кластеризации, можно его же использовать как БД, если не нужны сложные запросы-выборки.

читать миллиард файлов по 10 килобайт

пинг, допустим 100 мс * умножаем на миллиард, конец немного предсказуем

Число потоков же неограничено.

Хотя не, с редисом это опрометчиво сказал, столько ОЗУ за сколько-нибудь вменяемые деньги ты врядли найдешь.

SAS hdd стоит 300$ за 3 ТБ. Итого - 10К, грубо говоря, покрывают твои 100ТБ. Только надо как-то организовать эти 30 дисков. А если дублировать, то еще больше. Но это явно дешевле, чем амазон за 120к в год.

Имхо дешевле купить.

Вон выяснилось, что нужно всего 35-40 дисков. Даже их обвязка будет не космических денег стоить.

А по хранению со сжатием кто-нибудь что-нибудь может посоветовать?

я нет

но мне очень любопытно что и зачем генерит такие объемы?) ну не конкретно что, а сама суть.

Предрасчет отдельных ветвей дерева игры.

Предрасчет отдельных ветвей дерева игры.

Тут реально надо обдумывать что-то с сжатием данных. Ибо 100 ТБ это нехилый размер. И скорее всего он нехило сжимается, если не секрет выложи примерно в каком виде будут значения, тогда возможно подскажут как лучше это сжать.

Ключ - строка ходов вроде «A/B/C/...», в среднем 50-100 байт, значение - матрица чисел с плавающей запятой, около 10 килобайт (для простоты можно закодировать одной строкой). Требуемый доступ - просто по заданному ключу. Т.е. сжимать надо в первую очередь значения, причем лучше не по отдельности, а все вместе. Вопрос в том, как это сделать, чтобы была возможность достаточно быстрых чтения/записи.

Я думаю надо сделать примерно такое:
Отсортированные ключи разбить по большим файлам в которых одинаково начало до определенного хода. Это позволит сократить размер данных(не хранить начало ключей).
В этих файлах ключи должны быть выровнены до определенной длины и не быть сжатыми, да это увеличит размер(они всего-то 1% от данных занимают и мы ведь сократили на начале имени ключа) но зато позводит вести двоичный поиск по жесткому диску.
Дальше надо определить как эффективнее сжимать значения:
Если особой выгоды от попыток найти похожие значения для более лучшего сжатия нет, то просто для каждого файла ключей брать значения и паковать в архив где каждое значение это файл с номером. Где номер это номер строки ключа.
Если-же есть выгода от сжатия значений для ключей которые находятся в разных файлах, тогда в файлах ключей в конец просто дописывать в бинарном виде номер архива значений и номер значения в этом архиве(максимум 10 байт дополнительных для каждого ключа)
Осталось только алгоритм сжатия выбрать, например если критична скорость и объем занятой памяти, то не использовать непрерывное сжатие. Пусть сжатие будет чуть хуже, но зато доставать будет быстрее. Тут еще надо посмотреть нужна ли такая точность чисел и возможно попробовать чуть подкорректировать все значения так чтоб было больше похожих значений и больше степень сжатия.

числа изначально строки? или они в машинном представлении?

и буду через апи создавать/читать миллиард файлов по 10 килобайт (пишут же, что объем без ограничений)? Или что-то этому все же помешает?

помешает. Скорость. Ты их миллиард лет будешь читать. Да, «без ограничений»

Riak с бэкендом LevelDb - будет тебе сжатие.

Изначально - двумерный массив в Java. А как читать/писать его в базу, значения не имеет.

Можно попробовать HBase. Там вам и сжатие (LZO, Gzip, Bzip2, Snappy), и MapReduce для предрасчетов (через hadoop streaming можно логику хоть на brainfuck писать), и масштабирование с отказоустойчивостью. У меня 3Тб база крутится и кушать не просит.

Ну или Cassandra, ее чуть попроще настраивать, на мой взгляд.

Кстати, есть еще вот такая штука: http://www.mapdb.org/, Off-heap хранилище с интерфейсом как у HashMap. Ежели не хочется долбаться со всякими распределенными системами.

http://en.wikipedia.org/wiki/Trie

возможно спасет встроенное сжатие во всяких hbase и кассандрах. Ты с софтом определился уже?

Кстати, известно, сильно большая разница будет между A/B и A/B/C? А то, может, лучше будет хранить деревом с разницей?

Читаю про подобные cassandra базы данных со сжатием. Скорее всего, что-то подобное и выберу.

Там всё не очень понятно, удобнее все хранить в виде key-value и сжимать.

redis

Redis is in-memory data store

in-memory

Предлагаешь затариться 100тб оперативки?

Тред не читай @ сразу отвечай

Hadoop? HBase?

Если попроще, то да, как уже сказали - Riak. Cassandra норм, но искаропки нет MapReduce

Нужно провести некоторые вычисления
50-100 терабайт

Предвижу очень долгие вычисления и очень долгий процесс передачи по сети такого объема данных. Да, целых 100 терабайт - это очень ценная информация наверно

мнения админов локалхоста тут только и не хватало.

а почему тред в Talks, кстати?

вопрос - двумерный массив чисел или строк. просто 10кбайт чего ты имеешь. если строк так они сожмуться так что от 10 кбай хорошо если 1кбайт останется. а если чисел, то фиг его. но раз в ява, предполагаю что float или double. кстати, если double а точность такая не нужна, то сэкономишь примерно вдвое просто перейдя на флоат.

мнения админов локалхоста тут только и не хватало

Погодь, ты хочешь сказать что сто терабайт данных быстро передаются по сети? Я к тому сказал, что может быть если есть возможность не сохранять такие данные, а вычислять при необходимости, то лучше вычислять.

Я к тому сказал, что может быть если есть возможность не сохранять такие данные, а вычислять при необходимости, то лучше вычислять.

у человека конкретная задача - сохранить данные в базу.
ты предлагаешь ему этого не делать.

10 килобайт чисел (по 8 байт на одно число), точности флоата не хватает.

а почему тред в Talks, кстати?

В Talks людей больше.

Такой вопрос по поводу хранения при помощи своего велосипеда: если хранить сами записи (без ключей) в одном большом файле, лежащем на Reiser4 с gzip-сжатием, и обращаться к ним через memory mapping, то это будет тормозить?

Такой вопрос по поводу хранения при помощи своего велосипеда: если хранить сами записи (без ключей) в одном большом файле, лежащем на Reiser4 с gzip-сжатием, и обращаться к ним через memory mapping, то это будет тормозить?

Лучше всего взять и потестировать, ведь фейковые ключи нагенерить это не проблема.

лучше спросить в их листе рассылки, ибо по-умолчанию там работает довольно хитрая логика

Тут реально надо обдумывать что-то с сжатием данных

Тут нужно реально что-то делать с разработчиками игры.

в одном большом файле
то это будет тормозить

Естественно, чудес не бывает.

подточи «эвристики»