Как организовать работу с огромным объемом информации?

Question

[Nestratov]

Здравствуйте. Помогите найти решение. Есть коды, вида as2dSd9, их около 50.000.000. Посоветуйте, где хранить эту информацию, может быть БД какую нибудь. Как это грамотнее организовать? Работа с информацией будет на php и ,наверное, c#.

Comments

[Rpsl]

c какой целью их нужно хранить?

[Nestratov]

@Rpsl , нужно будет потом делать проверку - есть ли данный код или нету, удалять.

Answer 1

[Andrey Dugin]

Структура типа Radix Tree, на мой взгляд, подходит идеально:
en.wikipedia.org/wiki/Radix_tree

Answer 2

[Rpsl]

Если сложных выборок не требуется и оперативная память позволяет, то можно хранить хоть в key-value хранилище.

Например класть в редис, где код является ключем:
insert->('as2dSd9', 1)

Потом просто проверять есть такой ключ или нету.

Можно убрать в mongodb или mysql, но это будут более дорогие решения в плане памяти и скорости доступа, т.к. требуется обслуживание индекса.

Answer 3

[Тимур Сергеевич]

Ну так в Mysql можно)

Answer 4

[Андрей Федоров]

Я бы редис посоветовал. Быстрый key-value хранилище. Ключ - значение кода. Если для вас нужна скорость.
Хотя думаю и (My | Pg)SQL справятся с индексом на 50кк записей.

Answer 5

[Андрей]

Вдогонку к предыдущим ораторам. Я бы сделал так:
1. Основное хранилище - redis. Ежели нужно хранение атрибутов, то надо смотреть в сторону hashes. Если же надо просто проверять наличие ключа в базе - можно, как и раньше, хранить инфу в формате key -> 1.
2. Хранилище "на всякий случай" - на sql. То есть, если предполагается активный апдейт данных, то надо учесть, что redis - не ACID хранилище, то есть часть данных может потеряться при сбое. Если же обновление данных не будет активным - от дополнительного хранилища можно отказаться.

Answer 6

[Иван Старков]

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

Поэтому если важна скорость (миллионы проверок в секунду на наличие ключа) то хранить можно хоть в текстовом файле,
а для проверки создавать програмный хэш, (map, set) и загружать значения при старте сервера, 50 миллионов ключей не так уж и много и для стандартного std::set это примерно (зависит от реализации)
(sizeof(key)+sizeof(_Rb_tree_node_base))*50000000 = (20+16)*50000000 = около 2х гигабайт (тут можно налететь на ограничения скриптовых языков на память но недолго написать такой простой C++ модуль)

Если скорость не важна и устраивает на уровне несколько тысяч проверок в секунду то вам правильно советуют redis или любое другое key value хранилище, сразу есть где хранить, сразу есть api для любых языков
но редис тоже по сути inmemory база т.e память любит

Отсюда если важна память а скорость совсем неважна - сотни проверок в секунду, то добро пожаловать в мир sql или подобных баз.

Answer 7

[LucemFerre]

Исходя из задачи, скорее всего, наилучшим решением будет SQL. Если твой код вида as2dSd9 уникальный, то на это поле будет правильно сделать primary key. Тогда операция поиска по коду будет достаточно быстрая.
Если коды не уникальные, и критична скорость работы, можно использовать партицирование, т.е. разделение данных на несколько таблиц. К примеру, берешь набор первых символов, и делаешь для каждого символа свою таблицу. Соответственно, у тебя количество данных в одной таблице сокращается в десятки раз. Варианты, как партицировать, могут быть разные. Можно от того же первого символа брать ACII код, и делить таблицы по остатку от деления на какое то число. Соответственно, меняя число меняешь количество таблиц. Смысл в том, что бы количество данных в таблице давало приемлемую скорость выборки. И не забудь про поисковый индекс ;)

Так же не будет никаких проблем с работой с этими данными как из PHP, так и из C#

Comments

[Nestratov]

@LucemFerre , интересно)

Answer 8

[afiskon]

50 миллионов - это не так уж и много. Спокойно поместится в один PostgreSQL на нормальном железе.