Коммерческое веб-приложение - масштабируемый дизайн базы данных - PullRequest
Новая
       8

Коммерческое веб-приложение - масштабируемый дизайн базы данных

2 голосов
/ 13 мая 2010

Я разрабатываю набор веб-приложений для отслеживания научных лабораторных данных. В каждой лаборатории есть несколько сотрудников, каждый из которых будет иметь доступ как к своим данным, так и к данным своей лаборатории в целом. Таким образом, ожидается, что многие типичные запросы будут возвращать записи нескольких членов (например, моя мышь, мышь Джо и мышь Салли).

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

На данный момент я пришел к выводу, что большинство таблиц заканчиваются двумя полями: user_id и labgroup_id. Предложение WHERE любого оператора SELECT будет включать соответствующую ссылку на одно из полей идентификатора ("... WHERE 'labroup_id = n ..." или "... WHERE user_id = n ...").

Мои вопросы:

  1. Это подход, который будет масштабироваться до 10 ^ 6 или более записей?

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

Заранее благодарю всех, кто ответил.

1 Ответ

3 голосов
/ 13 мая 2010

Вы должны быть более чем хорошо, используя этот подход с 10 ^ 6 строк. В настоящее время мы используем нечто очень похожее со смешанными данными о клиентах, дифференцированными по идентификатору учетной записи с 10 ^ 8 строками, и вообще не испытываем проблем с производительностью на скромном оборудовании.

Убедитесь, что у вас есть определенные индексы, которые охватывают user_id и labgroup_id.

Помните, что MySQL может использовать только один ключ на запрос. Посмотрите на ваш типичный шаблон запроса. Если люди будут использовать несколько столбцов в предложениях where, создайте составные ключи, включающие часто используемые столбцы, которые также обеспечивают хорошую дифференциацию (то есть помогают сузить строки ... столбец да / нет - плохой ключ, но столбец с множеством различных значений, часто используется в предложении where может быть хорошим кандидатом).

Включите журнал медленных запросов MySQL (или получите коммерческий анализатор запросов или его 30-дневную пробную версию) и посмотрите, какие запросы занимают много времени. Используйте команду EXPLAIN, чтобы выяснить, какой индекс используется и как. Если определенный запрос часто появляется в журнале медленных запросов и / или с очень длительным временем выполнения, рассмотрите возможность изменения ваших индексов или добавления нового.

Убедитесь, что my.cnf правильно настроен для вашей среды. Стандартная конфигурация почти всегда очень плохая. Вот хорошее руководство к этому.

...