2016-02-15 3 views
0

У меня есть ситуация, когда я хотел бы хранить около одного терабайта информации в формате базы данных для поддержки запроса. Я не испытываю, когда дело доходит до дизайна базы данных, что частично объясняет, почему я хотел бы спросить, как это сделать должным образом.Дизайн базы данных для нескольких таблиц одного типа

У нас есть набор тестов, который создает множество информационных полей для каждого обновления состояния. Около 400 отдельных 64-битных полей информации для каждого обновления состояния, и мы хотели бы сохранить около 400 миллионов информационных тиков. Проблема в том, что мы получаем обновление информации примерно с 1600 компьютеров.

Полезный (для нас) запрос базы данных был бы в формате «Я видел, что это поле имеет значение X, а 5 состояний ранее, то же поле имеет значение Y?»

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

Есть ли какая-то методология дизайна, которую я пока не понимаю? Мне кажется, что 1600 таблиц - желательная черта, потому что это похоже на то, что запросы могут выполняться параллельно?

Подводя итог: Учитывая, что несколько идентичных машин работают немного по-разному, и я должен хранить последние тики состояния 250k - 1M, которые у них были, как мне создать базу данных? Моя нынешняя идея - создать таблицу на тест, где каждая строка представляет состояние в момент времени T, T + 1, T + 2 и т. Д.

Является ли это оптимальным? Или есть лучший подход, чем его дизайн? Как долго мои запросы будут занимать 1500-3000 таблиц из примерно 250 тыс.-1М записей (так как я хочу запросить весь набор данных?) Могу ли я получить лучшие результаты с использованием другого подхода?

1500 тестов, 400 64-битных переменных, хранящихся на одном типе состояния. От 250 кГц до 1 М за каждый тест, и я хотел бы иметь возможность хранить и запрашивать весь этот набор данных быстро и эффективно. Каков наилучший подход?

+0

Ваш вопрос не ясен для меня. – Fanda

+0

Наличие 1600 таблиц/коллекций не имеет смысла. Считывание всегда должно выполняться параллельно. И поскольку различие может быть выражено как поле или комбинация полей, я бы поставил все наборы данных в одну коллекцию. –

+0

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

ответ

1

Я бы всегда предпочитал одиночную таблицу/коллекцию, когда каждый тестовый шаг должен быть идентифицирован идентификатором теста и идентификатором шага. Например:

MySQL (денормализованной)

шаги

id test  step  data 
1 "Host_Test" "Step01" [serialized data] 

MySQL (нормированный (частично))

шаги

id test  step 
1 "Host_Test" "Step01" 

stepd etails

step_id data_key data_value 
1  "key"  "value" 

MongoDB

{ 
    _id : "1", 
    test : "Host_Test", 
    step : "Step01", 
    data : { 
     key1 : value1, 
     key2 : value2 
    } 
} 

Тогда вы можете, конечно, идентифицировать данные на тест по идентификатору теста.

Если вы тестируете в памяти, то хранение данных в базе данных/диске всегда будет вашей основной слабой точкой. Написание одной большой таблицы/коллекции не будет основным моментом.

+0

Есть ли способ сделать это быстрее. Реальность для каждого запроса, мне интересно узнать, какой тест удовлетворяет условиям и сколько тестов в целом удовлетворяют каждому условию. –

+0

Настройте сервер базы данных, чтобы работать как можно больше в памяти (отложить операции с диском). Попробуйте посмотреть на redis: http://redis.io/. – Fanda

Смежные вопросы