быстрое крупномасштабное хранилище ключей для программы php - PullRequest
3 голосов
/ 26 декабря 2011

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

Я получил размер кусков равным 20-30 байтов, и он может быть меньше, в основном это 2 8-байтовые целые числа и число с плавающей точкой, из которых состоят фактические данные.

Из-за масштаба, который я ищу, и количества создаваемых им кусков, я ищу альтернативу mysql, которая показала значительные проблемы при значении, значительно ниже моей цели.

В настоящее время я думаю, что хранилище значений ключей будет лучшим вариантом для этого, и я изменил свой код соответствующим образом.

Я пробовал число, но по какой-то причине все они, кажется, масштабируются даже меньше, чем mysql.

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

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

* * * * * У мембраны

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

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

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

Мне не нужно иметь строки или другие абстракции более высокого уровня, они в большинстве случаев бесполезны в этом случае, и я уже сделал код из некоторых других моих тестов, чтобы перейти к хранилищу значений ключа, и это похоже на скорее всего, будет самым быстрым, так как у меня есть только 2 вещи, которые будут извлечены из строки, связанной с третьей, поэтому для использования хранилища значений ключей не требуется дополнительной работы. Кто-нибудь знает какие-нибудь простые в использовании проекты, которые могут масштабироваться таким образом?

Я использую это хранилище для хранения отдельных наборов из трех чисел (размеры основаны на том, как они были сохранены в mysql, что может не соответствовать действительности в других местах хранения) 2 восьмибайтовых целых числа, одно для идентификатора document и one для идентификатора слова и плавающего представления пропорции документа, которым было это слово (количество раз, когда произведение появилось, деленное на количество слов в документе). Индексом для этих данных является слово id и диапазон, в который попадает идентификатор документа, каждый раз, когда мне нужно извлечь эти данные, будут все результаты для данного идентификатора слова. В настоящее время я превращаю слово id, диапазон и счетчик для этого слова / диапазона в каждое двоичное представление чисел и объединяю их, чтобы сформировать ключ вместе с двузначным числом, чтобы сказать, какое значение для этого ключа я храню, идентификатор документа или значение с плавающей точкой.

Измерение производительности было несколько субъективным, глядя на результаты процессов, помещающих данные или извлекающих данные из хранилища, и наблюдая, как быстро они обрабатывали документы, а также быстро обновляя мои статистические счетчики, которые отслеживают более точную статистику того, насколько быстро Система работает и смотрит на различия, когда я использовал каждый метод хранения.

Ответы [ 2 ]

5 голосов
/ 26 декабря 2011

Вам необходимо предоставить больше данных о том, что вы действительно хотите сделать ...

в зависимости от того, как вы определяете быстрая крупная шкала , у вас есть несколько вариантов:

и ооочень .. список становится довольно большим ..

Редактировать 1:

За это сообщение я бы сказалчто вы посмотрите на Кассандру или Волдеморта.Cassandra - не просто хранилище KV per se, поскольку вы можете хранить гораздо более сложные объекты, чем просто K -> V

, если вы хотите проверить cassandra с помощью PHP, взгляните на phpcassa ,но redis также является хорошим вариантом, если вы установите реплику.

2 голосов
/ 10 февраля 2012

Вот несколько продуктов и идей, которые не были упомянуты выше:

  • OrientDB - это база данных графиков / документов, но вы можете использовать еехранить очень маленькие «документы» - это чрезвычайно быстро, легко масштабируется и оптимизировано для обработки огромного количества записей.

  • Berkeley DB - Berkeley DB - этохранилище значений ключей, используемое в основе многих баз данных графиков и документов - предположительно, имеет SQLite-совместимый API, который работает с PHP.

  • shmop - общий доступОперации с памятью могут быть одним из возможных подходов, если вы готовы сделать какую-то грязную работу.Если ваши записи небольшие и имеют фиксированный размер, это может сработать для вас - использовать фиксированный размер записи и заполнение нулями.

  • handlersocket - это имеетбыл в разработке в течение длительного времени, и я не знаю, насколько это надежно.Это в основном позволяет использовать MySQL на «более низком уровне», почти как хранилище ключей / значений.Поскольку вы обходите анализатор запросов и т. Д., Он намного быстрее, чем MySQL в целом.

Если у вас фиксированный размер записи, мало записей и много чтений, вы можете даже подуматьчтение / запись в / из плоского файла.Вероятно, далеко не так быстро, как чтение / запись в общую память, но, возможно, стоит задуматься.Я предлагаю вам взвесить все плюсы и минусы специально для требований вашего проекта, не только для продуктов, но и для любого подхода, который вы можете придумать.Ваши требования не совсем «основные», и решение может быть не таким очевидным, как выбор правильного продукта.

...