2013-02-27 4 views
1

Я пытаюсь разработать приложение, в котором пользователи могут импортировать свои электронные письма и искать их импортированные электронные письма. Поскольку это, вероятно, будет использоваться многими пользователями (легко 10k +), дизайн базы данных имеет решающее значение. С этими числами пользователей база данных, вероятно, должна будет содержать более миллиарда строк (электронные письма).Схема DB для хранения миллиардов электронных писем

Приложение должно будет иметь возможность быстро возвращать записи после того, как поисковый запрос будет опубликован в приложении. База данных будет подвергаться интенсивному поиску, и мне нужна помощь в создании таблицы (ов) базы данных для создания эффективной схемы db. У меня есть большой опыт работы с MySQL, но я где-то читал, что не должен идти таким путем и искать MongoDB или что-то в этом роде? Разница настолько велика или есть какой-либо способ, которым я все еще могу работать с MySQL?

  • от
  • к
  • предмет
  • Дата (диапазон)
  • вложения (имена & типы только)
  • содержание сообщения
  • структура
  • (необязательно) Почтовый ящик/папка

Это поля для поиска, конечно, все электронные письма будут содержать еще два «столбца» для уникального идентификатора и user_id. Я нашел несколько db-схем электронной почты, но я не могу найти документацию о схеме, которая будет работать с более чем миллиардом строк.

+1

Это что, тысяча миллионов, или миллион миллионов? ':)'. Если вы, возможно, достигнете этого уровня, получите внешнюю службу, чтобы сделать это. Я подозреваю, что должно быть решение для хранения электронной почты, с которым вы можете взаимодействовать с использованием API. Тем не менее, быть реалистом в том, что вам нужно: может ли это быть преждевременная оптимизация? – halfer

+0

1 000 000 000+ сохраненных электронных писем. Идея состоит в том, чтобы запустить это на облаке amazon (масштабируемое). Моя идея состоит в том, чтобы сохранить электронные письма в пакете в хранилище S3 после вставки важных (доступных для поиска) полей в БД. – Floris

+0

Что относительно Solr? –

ответ

1

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

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

Итак, начните просто, не оптимизируйте проблему, которая еще не существует, и посмотрите, как это происходит.

+0

Да, MySQL с sharding может быть хорошим началом. – halfer

+0

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

+1

@ulkas Если вы правильно используете sharding, для запроса таблицы потребуется всего несколько мс – Sammaye

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