Сохраните огромный станд.:: карта, главным образом на диске
Никто не сможет дать вам ответ на этот вопрос. И если они это сделают, они будут неправы.
Единственный способ узнать, какие ресурсы потребляет система, - это построить ее, а затем протестировать с использованием имитированной нагрузки . Это поможет выявить узкие места в системе (диск, база данных, память, пропускная способность сети).
Затем вы начнете итеративный процесс поиска наихудшего узкого места , переархивирования приложения или изменения компонентов системы, празднования, а затем повторения всего цикла тест-мера-исправление. Добро пожаловать в захватывающий мир управления производительностью приложений!
Вы также можете воспользоваться преимуществами облака, масштабируя свои ресурсы в зависимости от нагрузки. Когда система занята (например, вечером), добавьте больше емкости. Когда все тихо, удалите ресурсы, чтобы сэкономить деньги. Это именно то, что делает Fortnite .
В зависимости от того, какие данные вы хотите сохранить, вы можете рассмотреть возможность использования Amazon GameLift :
Amazon GameLift полностью управляемый сервис для развертывания, эксплуатации и масштабирования ваших многопользовательских игровых серверов в облаке. Amazon GameLift заменяет работу, необходимую для размещения ваших собственных игровых серверов, включая покупку и настройку оборудования, а также управление текущей деятельностью, безопасностью, хранением и отслеживанием производительности. Возможности автоматического масштабирования Amazon GameLift обеспечивают дополнительную защиту от необходимости платить за большее количество ресурсов, чем вам нужно, и в то же время помогают вашим игрокам находить и присоединяться к играм с минимальным ожиданием.
blockquote>Читая ваш вопрос, я подозреваю, что ваше заявление еще не было написано. Итак, самое время принять общие архитектурные решения (например, использовать DynamoDB вместо реляционной базы данных, поскольку она обеспечивает быструю и предсказуемую производительность с плавной масштабируемостью), но не слишком беспокоиться о мелких деталях. Во-первых, вам нужно сделать продукт, который люди хотят использовать. Это будет более сложной задачей, чем масштабирование для удовлетворения возможного спроса.
Сконцентрируйтесь на получении первых 100 пользователей, а потом побеспокоитесь о других 100 000.
8 ответов
Я сомневаюсь, что Вы найдете библиотеку, которая отвечает Вашим требованиям точно, таким образом, необходимо будет выбрать, какие 'функции' действительно важны для Вас и затем решают, приближается ли существующее решение DB достаточно.
Миллиарды записей являются большим набором данных любым фрагментом. В каком уровне записи сгенерированы? Сколько времени они сохраняются? Схема доступа изменяется со временем?
Всегда обновления с тем же объемом данных как оригинал?
Я предложил бы доказать окончательно, что решение DB не собирается работать прежде, чем запуститься к самокрутке, особенно если целостность данных является главной (и это обычно...), Поддерживающий тот объем данных по диску, надежно может определенно быть проблема. Вам нужен какой-либо вид семантики транзакции при изменении данных? Действительно ли клиент является многопоточным?
Смотрите на STXXL.
stxxl::map<> похож на него, делает точно, в чем Вы нуждаетесь.
Я использовал http://www.garret.ru/gigabase.html Gigabase в нескольких проектах, это имеет аккуратный интерфейс C++, я работал с миллионами записей без проблем, это поддерживает откат. Это имеет MIT как лицензия, также автор очень быстр, чтобы ответить на вопросы и исправить ошибки.
Вы могли использовать SQLLite, который является опубликованным достоянием Базы данных С открытым исходным кодом.
Я заключу их страницу в кавычки:
SQLite является библиотекой программного обеспечения, которая реализует автономное, без сервера, нулевую конфигурацию, транзакционный механизм базы данных SQL. SQLite является наиболее широко развернутым механизмом базы данных SQL в мире. Исходный код для SQLite находится в общественном достоянии.
И
Продолжающаяся разработка и обслуживание SQLite спонсируются частично членами Консорциума SQLite, включая: Adobe, Symbian, Bloomberg, Mozilla
При необходимости в легком дб, это могло бы просто быть им
BerkleyDB мог бы быть хорош для Вас. Это индексирует на основе строки, а не числа, но Вы могли отформатировать свое число как шестнадцатеричное число. Предполагаемый быть в значительной степени с такой скоростью, как это добирается для находящегося на диске поиска ключа/значения.
Вы будете, вероятно, иметь к самокрутке. я, вероятно, засунул бы его в несколько mysql таблиц и ленивой загрузки фиксированная размерная карта (lru). если Вы действительно wan't для предотвращения дб поместите <256 или безотносительно записей длины в фиксированных рекордных файлах произвольного доступа и сохраните большие записи как отдельные файлы.
В зависимости от рабочих характеристик Вам нужно, ответ отличается. Но, учитывая просто информацию в описании проблемы, я думаю, что DB является излишеством и мог на самом деле быть контрпродуктивным.
При сохранении каждой записи, поскольку файл, имя которого является своим ключом (т.е. ключ '1' соответствует файлу '1.dat' на диске) сразу после того, как это сгенерировано, является простым решением, которое избегает нескольких проблем. Принятие Вас управляет тем, на какой файловой системе программное обеспечение собирается работать при выборе файловой системы с хорошей целостностью данные должны иметь хорошую целостность. Вы могли написать много кода для того, чтобы собрать в группу записи в одном файле и затем иметь для волнения об изменении размеров, или Вы могли просто позволить файловой системе обработать это для Вас (это разработано для контакта с файлами, изменяющими размер). Вы могли волноваться о записи их ориентированным на многопотоковое исполнение способом в тот файл, или Вы могли просто позволить файловой системе обработать это для Вас (файловые системы разработаны, чтобы иметь различные процессы, пишущие в различные файлы одновременно). Вы могли волноваться о файлах, сохраненных частично к диску, и написать код для проверки на него, или Вы могли позволить файловой системе обработать это для Вас (журналирование и атомарные записи). Вы могли волноваться о планировании записей изменений вместе для скорости, или Вы могли позволить файловой системе обработать это для Вас (запишите кэширование).
В основном хорошая файловая система и ОС должны обработать все это для Вас и добавления базы данных сверху его, которая пытается копировать всю эту функциональность, просто создает больше сложности и более потенциальный для ошибок. Если необходимо индексировать данные различными полями, то база данных может иметь смысл, но в описании Вы сказали, что только необходимо индексировать данные тем же целым числом, вводят каждый раз.
Я согласен с другими, что BerkeleyDB, sqlite или gigabase должны быть хорошими решениями.
Но написать собственное решение тоже не должно быть слишком сложно.
У меня есть простое решение, но есть три предварительных условия:
- Вы можете как минимум сохранить в памяти
std :: vectorс элементамиnumkey. - Ваши ключи можно сделать непрерывными.
- После записи файла каждый размер записи данных имеет фиксированный
maxsize, то есть его размер не может быть увеличен.
Если эти предварительные условия выполнены, самым простым решением будет сохранение позиции файла (int64) каждого ключа (int64) в векторе в памяти. Для поиска просто найдите позицию файла из вектора, найдите в этой позиции, где вы найдете размер записи как ее первую запись, и прочтите size байт.