Масштабування та обмеження

storh — файлове сховище, а не рушій реляційних запитів. Практичні межі наведено з орієнтовними числами з тестів продуктивності (50k записів, Apple M1 Pro):

• Точковий доступ практично необмежений, якщо файлова система може обробити кількість файлів, а колекція використовує шардинг за UUID. Одне читання займає кілька мікросекунд; довговічний запис одного запису обмежений fsync — кількома тисячами операцій на секунду.
• Сканування сегментованого журналу, читання за курсором і читання за часовим інтервалом добре працюють приблизно до 1M записів, якщо розміри сегментів налаштовано відповідно до робочого навантаження. Масове додавання обробляє десятки тисяч записів на секунду; під час повторного відкриття для відновлення пошкодженого кінця журналу відтворюються сотні тисяч записів на секунду.
• Операції з чергою додають компактні події до одного довговічного журналу, тому додавання в чергу, отримання, завершення, повернення в чергу та очищення не створюють постійного потоку файлів для кожного завдання. Пакетне отримання й завершення розподіляють блокування та fsync між цілими пакетами.
• Сканування полів у окремих файлах у DocStore сповільнюється після приблизно 10k записів, оскільки під час кожного відповідного сканування потрібно обходити окремі файли. Оголошуйте індекси для полів, за якими виконуєте фільтрацію; запити на точну відповідність із індексом дають результат приблизно за мілісекунду незалежно від розміру колекції.
• storh не призначене для довільних реляційних запитів, з’єднань, фільтрації з активним використанням вторинних індексів чи аналітичного сканування багатьох полів. Коли потрібні такі шаблони читання, передавайте колекції до дзеркала SQL; якщо потрібні транзакції з кількома записами, зберігайте основні дані в повноцінній базі даних.

Використовуйте DocStore, коли переважають точкові читання, SegmentedLog — коли переважають додавання й упорядковане читання, а Queue — для простого довговічного розподілу завдань. Порівняння наведено в розділі Вибір рушія.