Предложение базы данных/языка сценариев для проекта с тяжелыми вставками? [закрыто]

Я изучаю проект, который ежедневно включает большое количество вставок. У меня будет список пользователей (например, набор пользователей 500k), для которых мне нужно ежедневно отслеживать определенные действия, связанные с ними.

Например, пусть есть набор из 100 пользователей, скажем U1,U2,...,U100

Мне нужно вставить их ежедневные оценки в мою базу данных.

Рассмотрим общий балл, полученный для пользователя U1 за период с 30 июня по 6 июля, следующим образом.

June 30 - 99
July 1 - 100
July 2 - 102
July 3 - 102
July 4 - 105
July 5 - 105
July 6 - 107

База данных должна хранить ежедневные оценки каждого пользователя, например

Для пользователя U1,

July 1- 1pt (100-99)
July 2- 2pt (102-100) 
July 3- 0pt (102-102) 
July 4- 3pt (105-102) 
July 5- 0pt (105-105) 
July 6- 2pt (107-105) 

Точно так же база данных должна содержать ежедневную информацию о полном наборе пользователей.

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

Мне нужно начать все с нуля. У меня есть опыт работы с PHP в качестве сценария на стороне сервера и MYSQL. Я запутался на стороне базы данных? Поскольку мне нужно ежедневно обрабатывать около миллиона вставок, о чем нужно позаботиться?

Соответствует ли MySQL моим требованиям. Если да, то какой механизм хранения следует использовать? Первоначально я предполагал создать пользовательскую таблицу с идентификатором пользователя внешнего ключа и ежемесячными таблицами результатов с датами в качестве полей. Позже мне предложили сначала записать данные в csv/excel, а затем загрузить их в таблицу после определенного периода.

Вставка файла делает ситуацию более благоприятной в этом отношении.

Или я должен попробовать другие базы данных, методы NoSQL?

Мне нужно поддерживать это хранилище данных и объединять эту информацию в еженедельные и ежемесячные отчеты. В одном из предыдущих случаев я обнаружил, что запросы MySQL занимают много времени при выполнении.

Любая помощь будет высоко оценена. Заранее спасибо.

Я думаю , вы получите лучший ответ на DBA.SE. Здесь речь идет больше о том, как, а не о том, что (да, у него есть компонент «что», но он ограничен и очень специфичен для баз данных, поэтому администраторы баз данных будут иметь более высокий уровень знаний. Я полагаю, что это также будет по теме, хотя я в последнее время не смотрел их список по теме.
Это больше похоже на задание визуализации\логирования, чем на задание базы данных (много вставок и отсутствие выборки, еженедельная отчетность).

Ответы (1)

Чтобы решить первую проблему:

У меня есть опыт работы с PHP в качестве сценария на стороне сервера и MYSQL. Я запутался на стороне базы данных?

Когда вы занимались разработкой на PHP, MySQL был инструментом, который вы использовали для управления своими данными. Ваше приложение использовало его для создания, чтения, обновления или удаления (CRUD) записей/объектов/строк информации. Если вам предоставили экземпляр/виртуальную машину (vm)/вычислительный движок от вашего интернет-провайдера, который использовало ваше PHP-приложение, то этот инструмент часто называют движком базы данных. Итак, если я правильно понимаю ваше заявление, вы использовали базу данных MySQL.

Что касается вашего второго вопроса:

Соответствует ли MySQL моим требованиям. Если да, то какой механизм хранения следует использовать?

Что касается базы данных, вам нужна функциональность, безопасная для транзакций, высокая емкость и (учитывая вставленные ежедневные записи) высокая доступность. MySQL, Oracle и Microsoft SQL — три широко используемые базы данных. Они доступны как в локальной, так и в облачной реализации. У MySQL есть варианты механизма хранения, подходящие для этого, например, их механизм кластерной базы данных. При 500 тысячах пользователей, вставляющих 1 запись в день, вы получаете в среднем 20 тысяч вставок в час. Хотя это не необычно высокая скорость вставки, я предполагаю, что ваш пикскорость ввода будет значительно выше. MS Sql и Oracle хорошо подходят для этой среды, но, как правило, для их эффективного использования требуется знание их функциональных возможностей на уровне администратора базы данных. Сказав это, я всегда был впечатлен вычислительными возможностями как Oracle, так и MS Sql, хотя на самом деле вам не нужно многого из этого, просто база данных, которая может очень быстро суммировать столбцы.

Обратите внимание, что это требование может исключать некоторые решения для облачных хранилищ данных, в которых установлены максимальные значения вставки. (Это можно преодолеть, но вам необходимо хорошо знать архитектуру хранилища и функции настройки.)

У меня есть минимальные знания о средах nosql, поэтому я не могу дать вам никаких мыслей.

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

Вы предлагаете мне InnoDB? с учетом безопасного подхода к транзакциям.
Учитывая ваши требования, да. Вам нужно будет прочитать об обработке транзакций , чтобы использовать предложения ACIDity InnoDB.