Рейтинг:0

Много связанных таблиц в NoSQL? Тонны подключений, но только 1 мастер?

флаг ph
Fly

Моя компания использует базу данных NoSQL (Mongo) для своего продукта. Однако их продукт невероятно медленный, что может быть связано либо с эффективностью их кода, либо с дизайном их базы данных.Хотя я не был нанят в качестве разработчика или системного администратора и не являюсь экспертом в проектировании БД, я нахожу последний очень интересным и подумал, что было бы интересно посмотреть, насколько обоснованы или неверны мои мнения об их дизайне БД.

Основное, что бросилось в глаза, это:

  • В базе довольно много разных коллекций. По сути, каждый вид различных существующих «объектов» в нашей системе имеет коллекцию (более или менее). Мне это кажется очень похожим на базу данных в стиле SQL, где вы только сохраняете связи между объектами, а затем выполняете запросы сразу из нескольких таблиц. Тем не менее, я думал, что преимущество NoSQL заключается в том, что более неструктурированный подход «все данные в одной коллекции» позволит сократить время выполнения запросов за счет некоторой беспорядочной структуры. Чтобы придумать случайный пример: допустим, у вас есть банковские счета в приложении и могут быть транзакции между счетами. В стиле SQL для меня было бы две отдельные таблицы, одна для учетных записей и одна для транзакций. Я думал, что стиль NoSQL вместо этого поместит соответствующие транзакции непосредственно под соответствующую коллекцию учетных записей. Реальные объекты и структуры в нашей кодовой базе намного сложнее, поэтому я понимаю потребность в большем количестве коллекций, но я просто подумал, что, возможно, их слишком много.

  • Помимо наличия отдельных коллекций, мы, кажется, делаем много отдельных запросов к этим коллекциям, даже если они семантически связаны друг с другом. Прав ли я в своем предположении, что эта процедура будет медленнее, чем имитация запроса на присоединение?

  • Более общий вопрос: кодовая база НАМНОГО слишком велика для меня, чтобы получить полное представление о наших системах, тем более, что я даже не играю роль разработчика, но могу ли я что-нибудь сделать, чтобы быстро увидеть, где могут быть запросы? быть плохо структурированным?

  • У нас есть несколько серверов БД, один из которых является мастером, а другие реплицируют мастер, чтобы быть резервной копией в случае сбоя.У нас также есть множество копий нашей системы, обращающихся к одним и тем же базам данных (ну, технически разные базы данных, но они работают на одном сервере). Иногда это создает массу одновременных подключений. Не лучше ли разделить «какая база данных является главной» между системами и выполнять копирование данных при низкой нагрузке? Итак, например, предположим, что у меня есть 3 сервера БД и 3 экземпляра системы. На данный момент все 3 системы имеют доступ к одной и той же главной базе данных, которая реплицируется на двух других узлах. Не лучше ли было бы назначить один сервер БД для каждой системы главным, чтобы соединения были разделены между серверами?

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

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.