mayton2019

По разному. Я думаю что разные DBMS (SQlite, Oracle) могут по разному обрабатывать группировку.
Правильный ответ на вопрос - посмотреть execution plan комадой
explain (plan) select ..... group by....;
Наперед угадать какой будет использовал алгоритм - невозможно. Как вы помните
язык SQL - это декларативный язык который декларирует свойства результата а не метод
которым разрабочик хочет что-то сделать.

Oracle например имеет много conditions для исполнения группировки например:
1) Какой оценочный объем выборки? Может ли она быть отсортирована in-memory (sort-area-size) в противном
случая будет external sorting в TEMP tablespace.
2) Есть-ли композитный или простой индекс по полям группировки? В этом случае будет index-scan.
3) Требует ли запрос немедленной выдачи первой пачки (хинт +FIRST_ROWS) или можно подождать
но получить весь объем быстрее. Это тоже влияет на выбор алгоритма.

Это всё эвристики которые влияют на выбор окончательного алгоритма.

И уже к сортированной выборке собственно применяется лямбда которая делает группирующую операцию
AVG, SUM, COUNT ... e.t.c. и выдает строки курсора.

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

Какая тут схема?

Давайте прикинем объем который понадобится. Что такое триллион?
Это 12 нулей. Или 1 000 000 000 000 элементов. Какая у нас data-row?
8 + 64 символов типа ASCII (байт подходит чтоб покрыть все символы).
Итого 72 байта на строку. Там можно еще поужимать биты в байтах но только
сложность повышает а большой пользы для дела не дает. Пускай будет ASCII == 1 байт.

Вобщем такой расчет

72000000000000 байтов на весь сегмент данных когда таблица загружена.
Или 65 терабайт. А сколько магнитных блинов надо прикупить? Возьмем популярный магнитный
Western Digital Purple 10TB 7200rpm 256MB WD102PURZ 3.5" SATA III при цене 290$
Порядка 7 штук надо. Вобщем готовте котлету денег 290$ * 7 = 2030$

По поводу DBMS. Да key-value здесь подходит. Можно начинать с LevelDb или RocksDb но у них
расход дисковой памяти на 1 строчку может быть больше чем я посчитал. Я ведь считал эконом-эконом
вариант в виде бинарного типизированного файла где все записи строго по 72 байта. Сколько именно
захватит РоксДб или ЛевлДб - чорт его знает. Вряд-ли документация об этом что-то говорит.
Но берите 1% датасета. Загружайте
и аппроксимируйте сколько выйдет после полной прогрузкуи. Это - надежный способ оценки.

AWS RDS - это те-же самые Oracle/Postgres/MySQL только запускаемые в хостингах Amazon.

Поэтому твой вопрос слегка скомкан. Что на самом деле тебе надо? SQL DBMS которая работает в облаке? Потому что изучать это ты можешь установив локально бесплатные версии Oracle Express и других соотвественно.

Ты работаешь с документами в Google Sheets. Каких возможностей тебе не хватает?

Обычно (99%) когда говорят об облачных БД имеют в виду NOSQL:
- Amazon DynamoDb
- Microsoft CosmosDb
- (у гугла тоже своё решение есть но я не вкурсе какое)

У них есть сильное конкурентное преимущество в виде дешевизны хостинга, бесконечного
размера и гарантированой пропускной способности. Тоесть оплаченной тобой пропускной
способности.

Но платишь за это ослабнной консистентностью. Впрочем для большинства современных
юзкейсов этого хватает.

Нашел информацию, что sqlite не поддерживает многопоточность.

Это не проблема для твоего приложения. Обеспечивай синхронизацию на уровне python и работай короткими
операциями (OLTP). insert/update по одной строчке.

А мультипоточность можно заказывать для долгоиграющих процессов. В боте таковых нету. Не должно быть вообще. Никогда не должно быть.

кластеризованые и некластерризованные индексы в бд это грубо говоря отдельная служебная таблица.

Скорее всего - нет.

Хотя кластеризация - близка к целям индексирования но я-бы сначала послушал оригинальный текст этого утверждения. А иначе получится что мы как в том анекдоте где Рабинович напевает Шаляпина.

Короче такая мысль. В этой задаче самое главное - нейронная сеть которая обучается и выдает на выходе некую модель.

База данных здесь - вторична. Собственно здесь даже хватит текстового (csv) файла. Насколько я помню чтобы
обучать НС нужно просто разделить выборку на две части. Обучающая 95% и контрольная 5%. И далее последовательно показывать нейросети все образцы. Для этого кейса подходит любая из известных баз. Но если делать экономно - то я-бы предложил использовать БД для измерений. Они называются time-series db. Классификатор здесь https://db-engines.com/en/ranking/time+series+dbms
Эти БД поддерживают быструю пакетную загрузку (batch) и выборку измерений в диапазоне времени. И по тегам (по виртуальным столбцам как-бы).

Берите любую бесплатную и которая имеет интерфейс к вашему языку программирования. Например Influx.

Два действия полностью противоречат друг другу.

Оптимизирую сайт по скорости загрузки

Добавляем индекс по полю publication

Во время интенсивной загрузки индексы и триггеры и констрейнты мешают. Их выключают обычно.

Вообще чтоб дальше продолжать обсуждать - надо задать много вопросов. Что вы делаете вообще? Вы 1 раз загружаете или каждый день будете загружать?

Это одноразовый запрос
SELECT COUNT(*)
или будете каждый день его дёргать?

Все эти вопросы важны чтобы понять в какую сторону вы хотите улучшать. Оптимизация БД - это система компромиссов. Вы в одном месте что-то отключаете или наоборот включаете чтобы получить перформанс. Но вы теряете что-то в другом.

Между ОЗУ и БД есть еще промежуточный вариант. Это различные key-value библиотеки для работы с хранением и поиском больших объемов данных. Из таковых я помню

• BerkeleyDb
  
• LevelDb https://github.com/google/leveldb/blob/main/doc/in...
  
• RocksDb
  

На самом деле их гораздо больше. Но автору и этих хватит. LevelDb создавался гуглом и под него есть разные API (C++, Java, C#). Почти все эти key-value библиотеки поддерживают 2 базовые структуры данных на диске (это HashTable, B+Tree).

Для твоей задачи прекрасно подходит дисковая хеш-таблица.

А если разумно партицировать твой объем - то можно и просто в CSV файлы разложить с гарантийным временем доступа.

При десятке запросов в секунду - подходит любая БД.

Я не знаю кейсов чтобы она (БД) почему-то не подошла. Если вы думаете что не подойдет - то напишите почему.

Есть несколько задач когда от реляционности отказываются сознательно.

- Bigdata
- Загрузка сырых или неспецифицированных данных для дальнейшей обработки
- Загрузка документов имеющих нереляционную природу (XML/JSON)
- Логгирование событий или просто запись данных из внешнего датасорса

По такой слабо-связной базе нельзя делать JOINS но брать по ключу можно key-value или можно
делать анализ крашей и аварий.