Какую базу данных следует использовать для отслеживания статистики и архивирования писем, отправленных через PHP

Question

Вопрос имеет две стороны.

1. Мы размещаем множество статических файлов для публичного скачивания.PDF-файлы, почтовые индексы, изображения, люди загружают тысячи каждый день.Мы отслеживаем счетчики в нашей базе данных MySQL, а детали отслеживаются в MongoDB (например, откуда и когда произошла загрузка).

2. Мы отправляем множество писем через PHP.Наше приложение имеет тенденцию отправлять сотни тысяч электронных писем каждый месяц, многие из которых являются информационными бюллетенями, уведомлениями и приглашениями для проектов.Эти отправленные электронные письма сохраняются в нашей базе данных MySQL с сериализованными важными данными (не тело и не фактический контент электронной почты, а только заголовки, получатель, время отправки и т. Д.)

Является ли MySQLхороший выбор для этого?Монго?Должны ли мы использовать что-то еще?Прямо сейчас и наша архивная таблица электронной почты, и таблица статистики загрузок стремительно приближаются к 2 ГБ каждая.

Примечание: к данным, которые мы храним, обращаются регулярно, поэтому о чем-то, чтобы хранить и забыть о нем, не может быть и речи.Мы используем статистику загрузок, чтобы уведомить авторов контента о том, что их количество загрузок достигло X, и мы используем архив электронной почты для проверки статуса доставки и т. Д. И показываем его нашим сотрудникам, которые отслеживают это на регулярной основе.(мы используем Sendgrid для показателей доставки)

Answer 1

Мои два цента:

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

Если вы чувствуете себя предприимчивым и хотите сделать что-то более современное и распределенное,возможно, взгляните на hadoop и hive, которые в то же время могут решить проблему хранения больших файлов, но требуют от вас изучения некоторых новых вещей.

Answer 2

Я немного поговорю с частью MongoDB.Я предполагаю, что вы используете хранилище MongoDB для быстрого доступа к данным и, возможно, к данным, которые вы можете получить и забыть, но это приятно иметь при работе с отчетами.Ключом к быстрому выполнению экземпляра MongoDB (помимо эффективных, действенных индексов и соответствующих запросов, разумеется) является обеспечение того, чтобы ваш рабочий набор данных помещался в ОЗУ.

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

2ГБ на самом деле не так уж велик для данных Mongoили даже для рабочего набора данных.Я видел размеры данных в многотерабайтовом диапазоне.На основании предоставленной вами информации, я думаю, что ваш выбор MongoDB подходит для обозримого будущего.

Answer 3

Я думаю, что mysql может хорошо служить вашей цели.это более гибкий веб-интерфейс, для отслеживания вашего журнала вы можете использовать движок mysql ARCHIVE db.У mysql есть другой движок БД для разных целей.Я думаю, что архив будет лучше всего соответствовать вашей структуре.

в последнее время я управляю базой данных MySQL 60 ГБ.Это была масштабная база данных, и производительность хорошая.