Всем привет, есть проект в нем используется MONGO БД
за одну -2 секунды в базу, если они не существуют, заносятся новые строки порядка 2500. Все бы ничего, но база начинает притормаживать и дико ест процессор, если произвести запрос с большой выборкой, вообще все тормозит и падает. Как лучше оптимизировать систему? может быть присмотреться к редис?
Полная Версия: Оптимизация БД
vcjaenhy
Зависит от задачи. Если данные можно хранить временно - можно и редис.
Зависит от задачи. Если данные можно хранить временно - можно и редис.
допустим так
в хранилище должны ежесекундно поступать либо новые, либо уже размещенные в бд данные, в таком случае просто обновляется метка времени актуальности данных.
Данные, если они не актуальны, из оперативной бД(redis, mongo), переносятся в бд на жестком диске(mysql, postgre), через 5 минут.
При этом из-за объема переносимой информации, происходит подвисание всего хоста. Самое грустное в том, что если из бд на диске извлекать информацию хост так же подвисает. Как лучше организовать архтектуру?
в хранилище должны ежесекундно поступать либо новые, либо уже размещенные в бд данные, в таком случае просто обновляется метка времени актуальности данных.
Данные, если они не актуальны, из оперативной бД(redis, mongo), переносятся в бд на жестком диске(mysql, postgre), через 5 минут.
При этом из-за объема переносимой информации, происходит подвисание всего хоста. Самое грустное в том, что если из бд на диске извлекать информацию хост так же подвисает. Как лучше организовать архтектуру?
Что бы сделал я:
При записи данных - писать из сразу на диск и в ОЗУ (в redis есть возможность установить срок хранения данных). Данные вытаскивал бы из redis. Если нужно что-то из старых данных - я бы создавал кеш. Если даже при такой схеме все тормозит - надо менять хост, оптимизировать запросы, набрасывать индексы и т.д. Нужно смотреть по-ходу дела
При записи данных - писать из сразу на диск и в ОЗУ (в redis есть возможность установить срок хранения данных). Данные вытаскивал бы из redis. Если нужно что-то из старых данных - я бы создавал кеш. Если даже при такой схеме все тормозит - надо менять хост, оптимизировать запросы, набрасывать индексы и т.д. Нужно смотреть по-ходу дела
vcjaenhy, автор, думаю если покажете структуру, какие характеристики сервера и конфиг людям будет проще.
Эли4ка
4 ядра, 4 гига, 60 гб ssd
Zzepish
не получится данные сразу заливать на диск, тормозит сильно.
25000 в секунду, каждую строку проверить на наличие , обновить или записать
А как обычно в высоконагруженных системах выстраивается система логирования, я задумываюсь о том что бы репозиторий логов вынести на отдельный хост, сталкивались с таким в практике?
4 ядра, 4 гига, 60 гб ssd
Zzepish
не получится данные сразу заливать на диск, тормозит сильно.
25000 в секунду, каждую строку проверить на наличие , обновить или записать
А как обычно в высоконагруженных системах выстраивается система логирования, я задумываюсь о том что бы репозиторий логов вынести на отдельный хост, сталкивались с таким в практике?
| Цитата (Guest @ 15.08.2019 - 12:08) |
| 25000 в секунду, каждую строку проверить на наличие , обновить или записать |
Как именно делается проверка на наличие, при котором принимается решение об обновлении или записи? На стороннем сервере/сервере или внутри БД?
У меня есть смутное подозрение, плавно переходящее в уверенность, что эта проверка делается на некоем сервере в ПХП, Джаве или в Ноде. Прочитали, проверили, затем вставили или проапдетили... Сделали 2 операции в БД и погоняли данные туда-сюда несколько раз. Потратили на это много времени.
Но если внимательно прочитать доку по апдейту в Монго (ключевое слово "внимательно") https://docs.mongodb.com/manual/reference/m...lection.update/, то мы найдем волшебный параметр upsert. О коем говорится следующее: "Optional. If set to true, creates a new document when no document matches the query criteria. The default value is false, which does not insert a new document when no match is found.". То есть, вся проверка делается (может быть сделана) на стороне БД. Не надо никаких проверок на сторонних серверах!!!!!!!!!!!!!!! Просто даем команду и запись либо создается, либо апдейтится. Вобщем-то, подобное поведение есть в любой другой нормальной БД, будь то Мускуль, Постгрес, Оракл...
Так что прежде, что что-то думать про Редис, надо дооптимизировать Монго
Потому что при неправильном подходе и Редис легко будет "положить".| Цитата (Guest @ 15.08.2019 - 12:08) |
| 4 ядра, 4 гига, 60 гб ssd |
Ну и также не понятно, насколько данные параметры соответствуют задаче. По мне, так чем больше оперативки, тем лучше. Особенно если говорить про Редис (который не факт, что нужен). Он же в оперативке живет (в первую очередь там). И ему нужно пространство для работы.
ПыСы. Про индексы упомянули уже. Да, с ними тоже надо поработать очень внимательно. И еще учесть, что при быстром обновлении данных индексы тоже должны быстро обновляться, что также будет тормозить систему. Не совсем замкнутый круг, но однозначно зависимость имеется.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
Ребят сори забыл указать что система многопоточна, т.е. параллельно информация заносится с разных источников.
sergeiss
)
Да хоcтинг php, данные я добавляю/обновляю данные лишь через "upsert" - у функции обновления в монго есть переменная, которая указывает на необходимость добавления данных если нет строки с аналогичным ключом.
Кстати сейчас задумался, а можно ли так обновить множество записей... если даже можно то идея наверно не лучшая т.к запрос будет очень большим.
Индексы, ну серж, ну улыбаешь даже.
В целом был такой момент
Может быть кому пригодится, хочу обратить внимание что для каждой "строки" бд mongo создает уникальный ключ-хеш и если проиcходит постоянное добавление удаление данных то эти хеши если их не удалять накапливаются и тормозят систему.
Как я понимаю это происходит при создании нового ключа, когда бд проверяет используемые ключи и сравнивает их с возможными новыми.
И это да все учтено.
Нагрузки возрастают при перекидывании больших объемов данных в mysql
И большая их часть идет на скидывание информации о логах, уменьшать количество логов не хочется. Поэтому спрошу еще раз вынос логов на отдельный хост это нормальная практика?
sergeiss
)
Да хоcтинг php, данные я добавляю/обновляю данные лишь через "upsert" - у функции обновления в монго есть переменная, которая указывает на необходимость добавления данных если нет строки с аналогичным ключом.
Кстати сейчас задумался, а можно ли так обновить множество записей... если даже можно то идея наверно не лучшая т.к запрос будет очень большим.
Индексы, ну серж, ну улыбаешь даже.
В целом был такой момент
Может быть кому пригодится, хочу обратить внимание что для каждой "строки" бд mongo создает уникальный ключ-хеш и если проиcходит постоянное добавление удаление данных то эти хеши если их не удалять накапливаются и тормозят систему.
Как я понимаю это происходит при создании нового ключа, когда бд проверяет используемые ключи и сравнивает их с возможными новыми.
И это да все учтено.
Нагрузки возрастают при перекидывании больших объемов данных в mysql
И большая их часть идет на скидывание информации о логах, уменьшать количество логов не хочется. Поэтому спрошу еще раз вынос логов на отдельный хост это нормальная практика?
Т.е. в ходе работы модуль логирования системы не будет добавлять данные в бд, а отправлять post запросы к хостингу по соседству.
Не ясно, как учитывать id для связывания информации в логах.
Наверно вопрос всей темы можно сформулировать так -
как организовать архитектуру приложения, с учетом разделения временного хранилища, запросов для обработки информации и тяжелых запросов.
Не ясно, как учитывать id для связывания информации в логах.
Наверно вопрос всей темы можно сформулировать так -
как организовать архитектуру приложения, с учетом разделения временного хранилища, запросов для обработки информации и тяжелых запросов.
Guest
В хайлоаде огромный поток данных сливается в контролируемое количество потоков через очереди (RabbitMQ, например), и уже на эндпоинте происходит любая вставка/апдейт данных. И, да, как ты и сказал - логи надо выносить на отдельный хост. Обычно их пихают в noSQL бд.
В хайлоаде огромный поток данных сливается в контролируемое количество потоков через очереди (RabbitMQ, например), и уже на эндпоинте происходит любая вставка/апдейт данных. И, да, как ты и сказал - логи надо выносить на отдельный хост. Обычно их пихают в noSQL бд.
zzepish,а можешь привести пример или дать номральный линк почитать.
Все примеры что я видел описывают систему для отдачи наиболее востребованной инофрмации. У меня же задача иная это сбор и обработка информации.
И я уже начинаю понимать, что проектировать необходимо именно с учетом нагрузки и типа.
Т.е. сбор и быстрая обработка небольшого количества данных ложатся на сервак с оперативной бд, а рассчитанные данные с нее и общие данные перекидываются на сервак с бд на дисках.
Вопрос можно ли производить на "дисковом" хосте тяжелые рассчеты или же для этой задачи нужен отдельный хост.
Правильно ли я понимаю, что организация и стабильная работа системы может быть получена лишь в ходе тестов, т.е. просчитать пиковую нагрузку просто не возможно?
Все примеры что я видел описывают систему для отдачи наиболее востребованной инофрмации. У меня же задача иная это сбор и обработка информации.
И я уже начинаю понимать, что проектировать необходимо именно с учетом нагрузки и типа.
Т.е. сбор и быстрая обработка небольшого количества данных ложатся на сервак с оперативной бд, а рассчитанные данные с нее и общие данные перекидываются на сервак с бд на дисках.
Вопрос можно ли производить на "дисковом" хосте тяжелые рассчеты или же для этой задачи нужен отдельный хост.
Правильно ли я понимаю, что организация и стабильная работа системы может быть получена лишь в ходе тестов, т.е. просчитать пиковую нагрузку просто не возможно?
vcjaenhy
Конкретно линк не дам, ибо не знаю даже, найду пояснение или - нет. ПОкури просто отдельные элементы системы (rabbitMQ, mongodb, redis). Пойми, как они работают и т.д. Тогда сможешь более гибко их настраивать под нужды
Конкретно линк не дам, ибо не знаю даже, найду пояснение или - нет. ПОкури просто отдельные элементы системы (rabbitMQ, mongodb, redis). Пойми, как они работают и т.д. Тогда сможешь более гибко их настраивать под нужды
vcjaenhy
"сбор и быстрая обработка небольшого количества данных" -- это OLTP
"тяжелые расчеты" -- это OLAP
Попробуй гуглить что-то вроде "OLTP to OLAP synchronize" (сам процесс имеет название ETL).
"сбор и быстрая обработка небольшого количества данных" -- это OLTP
"тяжелые расчеты" -- это OLAP
Попробуй гуглить что-то вроде "OLTP to OLAP synchronize" (сам процесс имеет название ETL).
| Цитата |
| Нагрузки возрастают при перекидывании больших объемов данных в mysql И большая их часть идет на скидывание информации о логах, уменьшать количество логов не хочется. Поэтому спрошу еще раз вынос логов на отдельный хост это нормальная практика |
Речь же о "бизнес-логах"? Не о бинарных логах mysql или любых других служебных?
Несколько последних лет в моде ELK-стек.
_____________
Чатик в телеге
спасибо ребят
Здесь расположена полная версия этой страницы.