2017-02-20 24 views
0

Мне нужна экспертная консультация для моей базы данных. В основном у нас есть 100 датчиков по всему миру. Мы собираем данные с датчиков и храним их в базе данных для будущего использования.Доступ к большой таблице базы данных из нескольких потоков

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

Теперь число клиентов растет, поэтому количество таблиц и этот подход больше не выглядят хорошо (возможно, этот подход был не в порядке).

Теперь я хочу сохранить все данные в одной таблице, чтобы скопировать все данные из таблицы клиента в новую таблицу. Теперь размер новой таблицы превышает 5 ГБ с более чем 34 миллионами строк (и растет).

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

Как решить эту проблему? Есть ли другое решение? Должен ли я использовать внешнюю облачную службу для хранения данных?

Заранее благодарен!

EDIT: Я использую индексы. Вот схема таблиц

enter image description here

С UNIQUE INDEX idx_userInsDate (userID, instrumentID, utcDateTime)

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

+0

Невозможно ответить на такой широкий вопрос, без какой-либо информации о связанной схеме или указателях. В любом случае - * почему * используйте единую таблицу, если у вас есть такие четкие критерии разбиения, как идентификатор пользователя? Что относительно последствий * безопасности *? Одна уязвимость SQL Injection может отображать * данные каждого * –

+1

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

+0

В любом случае, вы не предоставили достаточной информации, чтобы дать конкретный ответ: «Не делайте этого». Схема базы данных не должна определяться количеством таблиц, но по конкретным требованиям и тщательным рассмотрением. –

ответ

0

С этой ограниченной информацией здесь мой совет.

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

Это на самом деле имеет несколько преимуществ, включая защиту от разоблачения информации о клиентах другому клиенту при несчастном случае, поскольку все их данные находятся в 1 таблице.

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

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

Независимо от того, что вы выбираете, вы должны учитывать ваши резервные копии sql, размер вашей базы данных и доступное место на жестком диске и т. Д.Если количество таблиц продолжает расти, возможно, каждый клиент должен получить свою собственную базу данных, но насколько сложно было бы вам сделать резервную копию всех этих баз данных и связать их с центральным db, если вам это нужно. Просто рассмотрите все, как это, включая безопасность и ваши потребности в отчетах, сколько данных вам нужно сохранить и т. Д.

Вот еще одна статья, которую я написал некоторое время назад на архитектуре данных с несколькими арендаторами. https://stackoverflow.com/a/38555345/671343

Проверьте это и, надеюсь, это вам поможет. Твой не единственный, кто должен бороться с дизайнерским решением. Просто взвешивайте все свои варианты, учитывая отчеты, безопасность, резервные копии и многое другое.

Надежда Thats полезные

0

Использование Монго или аналогичный DB для scenerio, то есть точная scenerio, которая требует Монго.

Multiple Запись Вставка сразу очень быстро и изолирован от других записей, следовательно, быстрее \

Чтения Быстрее если у вас есть правильная структура данных дерево формируется для ваших данных.

Надлежащее структурирование поможет ускорить создание таблицы для каждого клиента.

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

  • Нет связанных вопросов^_^