производительность базы данных

Question

Допустим, существует веб-сайт с 100 000 пользователей, каждый из которых имеет до 1000 уникальных строк, к которым можно добавить не более 100 000 000 строк. Было бы лучше иметь 1 таблицу, в которой каждая строка представляет собой одну запись вместе с идентификатором ее владельца. Таким образом, вы получите 1 таблицу с 100 000 000 записей с 2 ​​полями (текст и идентификатор пользователя).

Или иметь 100 000 таблиц, по одной таблице для каждого пользователя, а имя таблицы - это идентификатор пользователя. а затем 1000 записей в каждой таблице, с одним полем (текст).

Или вместо того, чтобы хранить строки в базе данных (было бы ограничено количество символов в длине SMS-сообщения), просто сохраните ссылку на текстовые файлы, где в каталоге 100 000 000 текстовых файлов, и каждый файл имеет уникальное имя случайные числа и / или буквы) и содержит одну из строк? (или где у каждого пользователя есть каталог, а затем его строки находятся в этом каталоге?)

Какой вариант будет наиболее эффективным: каталог и база данных, а затем какой из этих вариантов будет наиболее эффективным?

(в моем случае этот вопрос явно теоретический, но что делает сайт, подобный твиттеру?)

(под эффективностью я подразумеваю использование наименьшего количества ресурсов и времени)

Answer 1

Или есть 100 000 столов

Ради любви к Божеству, нет!Это приведет к ужасному коду - это не то, для чего предназначены базы данных.

У вас должна быть одна таблица с 100 000 000 записей.Серверы баз данных созданы для работы с большими таблицами, и вы можете использовать индексы, разделы и т. Д. Для повышения производительности, если это необходимо.

Answer 2

У вас будет одна таблица с индексами по USER_ID.

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

Answer 3

Вариант № 1

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

Хотя на практике вы бы хотели что-то вроде сегментированного кластера Монго, а не одинокий сервер с MySQL.

Answer 4

Это зависит от того, сколько активности сервер должен обрабатывать.

Несколько месяцев назад мы создали систему, которая проиндексировала ~ 20 миллионов рефератов статей Medline, каждая из которых длиннее вашего сообщения в Твиттере.Мы поместили материал в один индекс Lucene, который был размером ~ 40 ГБ.Даже несмотря на то, что у нас было плохое оборудование (2 ГБ оперативной памяти и нет SSD-дисков - плохие стажеры), мы смогли выполнить поиск по ~ 3 миллионам терминов за несколько дней в базе данных.

Одна таблица или (индекс lucene)) должен быть путь.

Answer 5

Определенно одна таблица, и заполнить записи на основе ключа.ОС будет сканировать со структурой каталогов из 100 000 имен файлов для сортировки ... один только каталог mgmt убьет вашу производительность (с уровня ОС)

Answer 6

Обратите внимание на базы данных NoSQL: http://nosql -database.org /