#mysql #mongodb #redis #database #nosql
#mysql #mongodb #redis #База данных #nosql
Вопрос:
У меня есть сервер приложений, который часто записывает данные в базу данных и считывает их в ближайшем будущем, но тогда очень редко эта запись данных считывается.
Какие хорошие базы данных оптимизированы для такого доступа? В настоящее время я использую MongoDB, но я думаю, что это, вероятно, не лучший выбор в данном случае.
Я открыт для реляционных баз данных (т.Е. MySQL), MongoDB, Redis и т. Д.
PS Кажется, легко ответить на этот вопрос для часто читаемого доступа к БД, но трудно найти информацию по этому конкретному случаю.
Ответ №1:
Это очень общий вопрос, нам нужно знать больше деталей
- Размер базы данных
- Рост данных, сколько 10 ГБ в день / 200 ГБ в месяц?
- Это OLTP-приложение или OLAP-приложение?
- Каково максимальное количество одновременных транзакций / пользователей?
Помимо этого, поскольку вы упомянули, что данные редко считываются после определенной точки
- Вы всегда можете посмотреть варианты архивирования (очистка в зависимости от продолжительности — ежемесячно / ежегодно)
- Разделение также является еще одним вариантом для более быстрого поиска
Опять же, вариант перехода на SQL или NOSQL основан на
- Согласованность
- Если у вас есть фиксированная схема, я бы посоветовал вам использовать реляционную БД
- Аспекты параллелизма, основанные на необходимости выбора SQL или NOSQL (пример — онлайн-банкинг я бы предложил RDBMS, для хранения обзоров продуктов / комментариев для сайта, я согласен с NOSQL, поскольку для этого не требуется обработка параллелизма)
Вам необходимо предоставить более подробную информацию о ваших потребностях в базе данных с точки зрения функциональности, объемов данных, использования данных и аспектов роста
Надеюсь, это поможет…
Комментарии:
1. Это приложение на основе OLTP. Размер базы данных сейчас невелик, но может быстро расти. Двоичных данных не хранится — только текст (без цифр, возможно, временных меток). Я пока не могу предсказать рост объема данных, но я ожидаю, что мне придется регулярно архивировать данные, чтобы обеспечить быстрый доступ к вставкам и новым данным. Может иметь много одновременных транзакций, но данные не обязательно должны быть реляционными. Данные пока не ссылаются друг на друга, и я не могу представить, как параллельный доступ может повлиять на это (поскольку каждый пользователь в значительной степени получает доступ только к своим собственным ключам).
2. Продолжая (максимальная длина текста), я бы хотел, чтобы схема была очень гибкой, пока я все еще нахожусь в стадии интенсивной разработки, поскольку ее, вероятно, придется часто менять, пока я ее не улажу. P.S. ОЧЕНЬ ПОЛЕЗНЫЙ ОТВЕТ! 😀
3. Я не уверен, насколько гибкая схема. Вы имеете в виду неструктурированные данные ?. Из ваших ответов как SQL, так и NOSQL достигнут вашей цели. Основываясь на навыках / удобстве разработчика с точки зрения SQL / NOSQL, вы должны принять этот вызов.
Ответ №2:
Поскольку вы упомянули MySQL, вы можете захотеть взглянуть на механизм хранения АРХИВОВ.