Предложения по выбору ключа сегмента

#mongodb #c#-4.0 #sharding

#mongodb #c #-4.0 #сегментирование

Вопрос:

мне нужна помощь в выборе ключа сегментирования в моем кластере с разделением mongodb.
Сценарий Мое приложение построено на .net core 2.1. То, что оно делает, на самом деле читает веб-сайты и обновляет данные в базе данных. У меня есть список из примерно 1 миллиона веб-сайтов, которые необходимо просмотреть. Приложение просто находит новые страницы, которых еще нет в моей базе данных, и сохраняет их в базе данных.

Сведения о кластере и сервере У меня есть 3 сегмента (по одному первичному и по 2 вторичных) на компьютерах Dell r820. Каждая машина имеет 512 ГБ оперативной памяти. И я запускаю свое приложение на 4 компьютерах Dell r620, его приложение mutithreadrd.

Структура базы данных: в основном у меня есть 2 базы данных: одна для всего списка домашних страниц и одна для страниц.

Домашние страницы:

_id

URL (ключ сегмента)

Страницы:

_id

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

Домашняя страница

Уже прочитано (индексированное поле)

Таким образом, приложение считывает домашние страницы и сохраняет внутренние страницы с домашней страницы в базе данных страниц. А другая часть приложения получает страницы из базы данных Pages, где AlreadyRead равно 0, обновляет его до 1 и сканирует его, чтобы сохранить другие страницы, найденные на этой странице, в базе данных. Но эта часть требует времени по мере увеличения размера данных, что, я думаю, связано с неправильным ключом сегментов, поскольку он установлен в поле URL, и команда выполняется для всех сегментов (я предполагаю). Я сохраняю URL-адрес без http или www. И если я установлю HomePageURL в качестве ключа сегментирования, он неравномерно распределит данные по кластерам (что я уже испытал, у него было 92% данных в одном кластере).

Короче говоря, учитывая приведенный выше сценарий, какой может быть лучший ключ осколка? Или я должен выбрать составной ключ осколка?

Комментарии:

1. Было бы здорово, если бы вы могли поделиться деталями индексации, поскольку они могут быть связаны с вашей проблемой производительности 🙂

2. AlreadyRead индексируется в pagesDB, а URL-адресу присваивается уникальный индекс, чтобы избежать дублирования записей в PagesDB