2014-10-29 8 views
-2

У меня есть проект для хранения и обработки расходов пользователя. В базе данных будет всего две операции: INSERT и SELECT. База данных может содержать миллионы записей в день (в зависимости от количества пользователей или если пользователь является компанией и т. Д.).Какую базу данных использовать и как ускорить

общие запросы:

  1. Показать расходы от date x до date y. (В основном)
  2. Применение фильтров по запросу (1).
  3. Показать расходы по определенному товару до даты. (Запросы по всей таблице)
  4. Показать все расходы до даты. (Редко)

1: Я запутался в какую базу данных использовать для этого: (Как в моем случае) SQL или NoSQL или SQL и NoSQL combinely. Мне нужно сравнение, основанное на скорости, при запросе большого количества данных.

2: Поскольку в день он может содержать миллионы записей, миллионы строк, полученные в результате запроса, должны быть переданы с сервера на клиент. (В моем случае есть еще одна накладная. Поскольку сервер базы данных удален от веб-сервера, результат должен быть перенесен с сервера базы данных на веб-сервер, а затем на клиента.) Как сделать это быстрее?

4: Если я выбираю MySQL, который будет лучше: а: сбросами всех данных в одной большой таблице SQL. b: Создание таблицы для каждого дня (с датой в виде имени таблицы), которая будет содержать меньшие объемы данных. (Я думал, что (б) будет быстрее, давая диапазон дат, так как я знаю, какую таблицу выбрать, а не искать в большой таблице и запрашивать конкретную дату.)

3: На данный момент я пытаюсь с MySQL. (Тестовые данные уже есть. Я использую скрипт python для анализа этих данных и отправки дампа в MySQL. Я могу отредактировать скрипт и заставить его работать для любого типа базы данных.) Я попробовал запрос (4) выше. В результате с сервера базы данных, моего веб-сервера/клиента (поскольку я тестирую, мой веб-сервер сейчас является клиентом.) Вид повешен, а около 13 миллионов строк в результате запроса переносятся с сервер базы данных. Таким образом, я использовал цикл в моем PHP кода, чтобы ограничить запроса 1000 строк, в то время как в примере ниже:

(Loop until getting data from database){ 
    i=0; 
    SELECT * FROM <Table> LIMIT i, 1000; 
    i+=1000; 
} 

Это по-прежнему медленно, но теперь система не висит во время передачи. Но LIMIT здесь будет работать, получите 1 000 записей (в то время как i=0), затем 2 000 записей (в то время как i=1000) и так далее. Или он получит 1 000 записей (в то время как i=0), Затем снова начните с 0, но пропустите 1 000 записей и получите 2 000 записей (в то время как i=1000) и так далее, что будет значительно медленнее. (Я искал в Интернете, чтобы узнать механизм LIMIT, но везде, где они говорят о LIMIT с ORDER BY, не о том, как получить данные с WIMIT и что влияет на производительность с ним.)

P.S. Я не база данных pro. Просто новичок.Поэтому задавайте предложения экспертов перед началом проекта.

+2

Скорость для реляционной базы данных будет зависеть от того, как вы структурировали и индексировали таблицы; все остальное вытекает из этого; но реляционные базы данных, такие как MySQL, отлично умеют обрабатывать миллионы записей быстро и эффективно, если они хорошо разработаны. –

+0

@MarkBaker Мой нынешний подход хранит данные в 5 разных таблицах, чтобы соответствовать уровню нормализации 3. Я знаю, что он может быстро извлечь несколько строк из миллионов записей. Но похоже ли это на получение нескольких миллионов строк из миллионов записей? – RatDon

+1

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

ответ

1

Если у вас есть миллионы записей в день, я думаю, вы должны пойти на базу данных NoSQL. Он будет более быстрым и эффективным при обработке больших данных. Я предлагаю elasticsearch для вас, поскольку вы выполняете только функции INSERT и SELECT на огромном количестве данных. Он имеет хорошую документацию и достаточно прост в использовании. Я думаю, что это послужит вам хорошо.