Алексей Черемисин

Если ошибка "Unauthorized", от очень возможно, что просто нужно прийти в базу с правильными логинами/паролями.

Из распределенных, и не очень, zokeeper или consul.io. И тот и тот могут работать в стандалон режиме, зато получите, в случае, чего возможность разнести на кластер. Я за консул, тупо удобнее. Оба очень легковесеые и поддерживают атомарные операции.,что хорошо, когда модифицируете дин ключ из разных мест.

Вообще-то noSQL бывает сильно разный, заточенный под совершенно разные задачи, которые очень плохо натягиваются на обычный SQL с его транзакциями, логированием, индексацией, и системой запросов.

Приведу несколько примеров, где noSQL выигрывает в разы. Причем, во всех задачах можно извратиться и на обычном SQL.

Представим задачу хождения по графам для анализа социальных взаимоотношений. На SQL мы получим пару десятков таблиц, или возьмем графовую базу данных.

Задача сбора и агрегации (обыкновенные счетчики) - можно взять и SQL, но обычно тут не нужны транзакции и связанные с этим накладные расходы, поэтому берем тарантул, редис или каффака.

Задача полнотекстового поиска по документам - решать ее на SQL, не очень приятное занятие, возьмем например солр/эластик/сфинкс.

Задача хранения объектов - на SQL ее тоже решать часть не с руки, особенно, когда структура самих объектов сильно расширяется. Возьмем монгу.

Задача хранения логов временных рядов с агрегацией - тут с SQL просто швах! Возьмем influxdb или clickhouse.

При этом, у SQL очень часто есть серьезный недостаток в масштабировании, что легко решается в noSQL.

Ах, да, очень часто ставят рядом и SQL и noSQL, и данные разбрасывают в разные базы по конкретным задачам.

На мой взгляд, архитектура хранения не очень правильная.
Делайте две коллекции. Одна для Категорий, вторая - для Товаров.
В Товар же добавьте поля: Бренд, Категория [array].

По характеристикам товара - у меня они, увы, не одинаковые, поэтому храню их в Товаре в виде массива объектов

{ name: Сапог сложный
  sku: smart-shoozze-$Цвет$-$Размер$
....
Характеристики: [
{name: Цвет, value: Зеленый, type: checkboх, sku: GREEN},
{name: Цвет, value: Красный, type: checkboх, sku: RED}
]
....
}

Для вывода фильтров - делаете по этому полю агрегацию.

Если уж по существу - еще есть коллекция Остатки. А еще есть коллекция Медиафайлы.

Если совсем глубоко - сделано на эластике, но проблем с монгой быть не должно.

Mvstore

Есть еще DataGrid - это все вместе взятое, да еще и в памяти (Hazelcast), да еще и с дисковым хранилищем (Apache Ignite). Тут тебе все сразу и Key/Value, и объекты (Document), и SQL, и распределенные, и BigData/BigTable.

Взять elasticsearch и в нем делать поиск, собственно в нем и хранить сами данные можно.

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

Elasticsearch!

Вообще-то это kibana, которая рядом с эластиком лежит.

Redis вам в помощь! https://redislabs.com/ebook/redis-in-action/part-2...
Еще хочу посоветовать посмотреть в сторону influxdb, в качестве хранения ваших коунтеров, отображать можно через grafana.

Смотря что с чем кушать. Можно и elasticsearch в качестве nosql хранилища использовать, как я делаю. Мы же, я надеюсь, подбираем не просто абстрактного коня в вакуме, а нечто, что поможет решить нам задачу.
Вот с описания задачи в вопросе я бы и начал.
Как пример:
- нужно много искать по разным критериям, типа товаров в магазине, желательно с языковым поиском, документы небольшие и не ветвистые - elasticsearch
- нужно искать непонятно что в развесистых документах, языковой и полнотекстовый поиск не сильно нужен, но нужно вычислять поля в зависимости от поиска - mongodb, как пример база расписаний поездов и их движения по направлениям.
-нужно искать связанную информацию типа связей между людьми, типа семи рукопожатий - node4j например.
Ну и так далее, для каждой затычки есть хитрый штопор.

Еще посоветую не обойти вниманием Elasticsearch. Очень интересные выборки можно делать. Вначале придется мозг немного взорвать, но потом пойдет как по накатанной.
У меня на осмысление всего ушло где-то месяца два неторопливого изучения. Скорости отдачи фантастические. Как раз стоял выбор между монго и эластиком. В результате элатсик победил новизной. Ну и я в свое время очень активно использовал люсину (поисковый энжин, который использует эластик), лет эдак 10 назад, поэтому примерно представлял, что это такое.
Единственное, что порекомендую, сразу брать библиотеку-клиент с автоматизацией запросов, голые запросы составлять еще то удовольствие. Я использую elasticsearch-dsl для питона.

Ну, а что у вас конкретно тормозит? Выборка из базы, передача, процессинг или обновление "хранилища"?
Здесь же универсального решения быть не может. В каких-то случаях можно пренебречь промежуточным хранением до завершения "длинной" транзакции, в каких-то это не очень хорошо.
Попробуйте все промежуточные данные о событии хранить в key-value базе типа redis.

Установите elasticsearch. В него загрузите свой файл построчно, один документ - одна строка, ключом - номер строки. И ищите сколько влезет.
А если просто нужно прогнать весь файл через сотню-другую алгоритмов, то загрузите в перколатор свои поисковые запросы и обрабатывайте весь файл за раз!

Хороший вопрос!
На третий взгляд, я бы поступил по следующему алгоритму.

Взял бы базу данных, ну например mysql.... Для хранения кешей и коллизий.
Итак, нам нужно пройтись по записям бигфайла, и сформировать новый бигфайл.
1) берем строчку файла, считаем от нее (или какой-то части), например sha1.
2) ищем по базе данных наш sha1
(таблица в "hashes" c полями "hash" и "offset", "count")
2.1) Если не нашли:

• копируем текущую строку в новый файл
  
• заносим наш sha1 и начало строки в базу (это нужно для коллизий)
  

2.2) Если нашли:

• из базы забираем смещение начала строки
  
• из старого файла вытягиваем всю строку по смещению и сравниваем
  
• если строки равны, то переходим на п1) (можно еще и обновить count этой записи)
  
• если строки не равны, у нас коллизия (!), обрабатываем ее
  

3) Обработка коллизии
(таблица в "collisions" c полями "hash" и "offset", "count")

• берем из collisions все записи по нашему хешу
  
• для каждой записи вынимаем строку из старого файла и сравниваем
  
• если строки равны, то переходим на п1) (можно еще и обновить count этой записи)
  
• если строки не равны, добавляем новую запись в таблицу collisions с новым смещением, текущюю строку пишем в новый файл
  
  

В принципе, этот процесс можно параллелить на бесконечное количество процессов. хотя, нужно бы еще над этим подумать.

PS. Можно еще дополнительное поле в каждой из таблиц сделать "count", обновлять его, если произошло сравнение записей, для статистики.