Есть задача: организовать хранение нескольких (около 5) миллиардов записей, которые можно медленно обновлять, но нужно быстро выбирать. Схема многомерная, т.е. каждая такая запись связана с другими через внешние ключи, которые также участвуют в критериях выборок.
Для примера пусть это будут автомобили на продажу/аренду, все их характеристики раскиданы по другим таблицам, по ним нужно искать. Автомобилей много. MySQL даже с индексами справляется с этим не очень.
Что делать? CouchDB? Hadoop? Или просто спроектировать нормально можно?
Всё-таки, не такое уж и большое число, миллиард этот.
Денег мало.
Шардинг и денормализация данных, БД имеет большей частью вкусовые значения.
То есть, минимизируйте внешние зависимости и следите за ними на уровне приложения. Небольшие таблицы лучше целиком хранить в каком-нибудь memory-хранилище (кеш приложения, nosql — не важно). Далее, явно разделите данные по основному ключу (скажем, номер продаваемого итема), и храните в разных БД. Если вдруг неожиданно окажется, что для не-сервисных операций нужны выборки, не связанные с основным ключом — вы либо что-то делаете не так, либо храните именно эти данные в другой бд.
PS Миллиард записей — это очень много, если к хоть сколько-то заметной части регулярно нужен доступ — просто оцените количество реальных обработок строк в секунду — с учётом оценки IO, CPU и памяти это даст грубую оценку количества необходимых серверов.
Кстати, у вас есть опыт хранения миллиарда ключей в монге? Тут коллеги пробовали 2.1, у них на ~400млн начинает всё сильно тупить на вставке, при этом там было 3 реплики и шардировано на 4 машины вроде, всё на ссд лежало + много памяти.
Нет. Более того, я не представляю, как в монге решать те или иные проблемы/сервисные задачи без глобального даунтайма. Развалившийся кластер — что-то вроде конца света для такого решения.
Имхо, на таких объёмах с ssd вполне можно использовать обыкновенный MySQL, в особо резких по CPU случаях через HandlerSocket.
Мускуль не катит, т.к. как только мастер отваливается — наступает readonly, и нормального режима переключения мастера автоматически, прозрачно для приложений и без геморроя нету.
Фейсбук тоже живёт, просто у них главная идея «датацентр надёжен и не может перестать работать». Можете кинуть пару-тройку ссылок с успешным опытом применения и с цифирками?
Да, я тоже думаю, что в подобных случаях архитектуру шардинга данных нужно строить с оглядкой на прикладную логику. На другом проекте мы так и делаем, только там главный квест — не объём данных, а скорость, отказоустойчивость и масштабируемость.
Я бы посоветовал использовать MySQL или что угодно другое, что будет поддерживать быстрые выборки по первичному ключу, а поиск по параметрам проводить через специальные средства — например, тот же sphinx.
Просто индексируете сфинксом свою базу, ищете ч/з сфинкс, он возвращает Id записи, по ид уже быстро вытаскиваете контент из MySQL.
Базарю для этого отлично подходят документоориентированные БД. У них как раз медленная запись, но очень быстрое чтение. Соответственно не нужны никакие внешние ключи, вся инфа по машине будет храниться в одном документе. Сам работал с RavenDB, но думаю для вас это не лучший вариант, можно посмотреть в сторону MongoDB. Миллиарды записей не проблема.
Простой
Простой
