MySQL или NoSQL? Рекомендуемый способ работы с большим количеством данных

Question

У меня есть база данных, которая будет использоваться большим количеством пользователей для хранения случайной длинной строки (до 100 символов). Столбцами таблицы будут: userid, stringid и фактическая длинная строка.

Так это будет выглядеть очень похоже на это:

Userid будет уникальным и Stringid будет уникальным для каждого пользователя.

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

Я предполагаю, что это приложение todo может закончиться 7 миллионами заданий через 3 года, и это пугает меня использованием MySQL.

Так что мой вопрос: Это действительно рекомендуемый способ обращения с большим количеством данных с длинной строкой (каждая новая задача получает новую строку)? и MySQL - это правильное решение для базы данных для выбора таких проектов?

Я еще не имел большого количества данных, и я пытаюсь спасти себя в будущем.

Answer 1

Это довольно простой реляционный вариант использования. Я не видел бы здесь NoSQL.

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

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

Что касается того, является ли MySQL правильным решением, это действительно будет для вас определять. Я бы сказал, что MySQL не должен иметь проблем с обработкой таблиц с 2 миллионами строк и 2 индексами на двух целых идентификационных полях. Предполагается, что вы выделили достаточно памяти для хранения этих индексов в памяти. Существует определенная информация о работе с MySQL, поэтому, если вы просто пытаетесь учиться, это, вероятно, будет хорошим выбором.

Answer 2

Это не вопрос «больших объемов» данных (mysql обрабатывает большие объемы данных только штрафом, а 2 mio-строки не являются «большими суммами» в любом случае).

MySql - это реляционная база данных. Поэтому, если у вас есть данные, которые можно нормализовать, они распределяются между несколькими таблицами, что гарантирует, что каждый datapoint сохраняется только один раз, тогда вы должны использовать MySql (или Maria или любую другую реляционную базу данных).

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

Answer 3

Независимо от того, что вы считаете «большим количеством данных», современные двигатели БД разработаны для многого. Вопрос «Реляционный или NoSQL?» не о том, какой вариант может поддерживать больше данных. Различные реляционные и NoSQL-решения будут обрабатывать большие объемы данных по-разному, а некоторые лучше других.

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

Суть в том, что количество записей, которые вы храните, не должно воспроизводиться в решениях SQL и NoSQL, это решение должно быть оставлено на том, как вы будете сохранять и извлекать данные. Похоже, что ваши данные уже нормализованы (например, UserID), и если вы также желаете согласованности, когда вы, например, удаляете пользователя (элементы TODO также удаляются), я бы предложил использовать SQL-решение.

Answer 4

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

Используйте таблицу InnoDB с составным первичным ключом на {userid, stringid}, и вы получите всю необходимую производительность из-за того, как работает кластерный индекс.