невозможно создать группирующие индексы
2. увеличив количество записей в 1 коллекции с 800к до 5 млн получил серьёзное замедление .find()
3. если при количестве 800к записей в коллекции поиск длился 560 ms, то с 5 млн длительность поиска возросла кратно
4. так например при 2.3 млн записей = 1.6 сек, при 5.2 млн = 3.3 сек
каким образом можно обойти это или решить?
п.с.
экспериментировал с ключами
с их длиной для каждой записи
с их типом полей текстовые или структурные
= результат поиска по длительности одинаковый.
из-за уникальности каждой записи, невозможно создать группирующие индексы Что мешает? Уникальность не помеха в чоздании индексов
каждая запись имеет такой вид: {"p": "provider", "w": warehouse, "a": article, "i": info} где: р - поставщик (текстовая запись не более 25 символов) w - название склада (не более 65 символов) a - артикул (не более 16 символов) i - [структура, с, объектами, данных] пробовал: так .create_index([('p', 'text')], name='p') (от каждого поставщика примерно 500-800к записей) и так .create_index([('w', 'text')], name='w') (в каждом складе от 1к до 230к записей) и так .create_index([('a', 'text')], name='a') (каждый артикул уникален) результат по скорости поиска не изменялся. скорость замерял с помощью: .explain()['executionStats']['executionTimeMillis'] может я чего не пойму в создании индексов? - доку вроде курил часа полтора, вычитал всё на офф сайте про индексы - окольные статьи перечитал - оверфлоу перегуглил - форумы перешарил
А сам планировщик что пишет? Он пользуется индексами в итоге?
хороший вопрос, надо глянуть на досуге
А выборка как выглядит?
.get_collection('name_collection').find({'a': '9037424004'}) - пример запроса выборка на скрине
Создавайте индексы по каждому полю и радуйтесь
5 млн индексов?
Обсуждают сегодня