mayton2019

Топик тегирован "Базами Данных". Какими - чорт его знает.

Поэтому есть следующие коробочные решения. Cassandra, Redis, Amazon DynamoDb. Все они поддерживают дополнительное поле TTL и удаляют записи автоматически без участия разработчика.

По поводу подводных камней о которых пишет автор. Это всё очень плохо и почти не работает в боевых условиях. Пока бэкап данных делается в обычном плановом режиме - никто не знает о существовании всяких там левых файлов на сервере приложений. Грубо говоря все думают что состояние системы (state) лежит в базе и только в базе. Поэтому попытка размазать состояние системы по нескольким нодам вычислительной сети приводит к сложным и трудноуловимым последствиям.

Для оптимизации загрузки landing page, можно хранить копии этой картинки в уменьшенном виде. 2000х1000 => 1000x500 => 500x250 e.t.c. Так игроделы делают для быстрого рендеринга текстур. Mip-уровни кажется называется.
Обновлять эти mip уровни можно не спеша. Через минутку.

База mysql вам вобщем-то не нужна. Картинку можно в реальном времени править atomic операциями и хранить в raw формате. Не знаю делают ли такое на PHP. Возможно вам нужен рукастый програмист на C++ или еще на каком-то языке чтобы подружить PHP с С++ и сделать сервис для этой картинки.

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

В идеале - реплицировать все данные в другую БД с другой геометрией таблиц или вообще в систему другого типа.

Любая современная биг-дата будет дешевле по стоимости владения по сравнению с DBMS.

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

Из java библиотек есть Guava, Jung, GraphT.

Xml обычно плохо подходит для баз данных. Если тебе надо изменить 1 атрибут в 10 мегабайтном xml файле то с точки зрения xml технологий это будет - создание нового документа с изменениями. Тоесть в перспективе такая бд будет плохо держать нагрузку.

Рассмотри варианты с mongodb+json. Там разработан специальный бинарный вариант сериализации json при котором эта проблема избыточной дисковой нагрузки будет устранена.

Я предлагаю словарь Python все таки оставить словарем и не искать натянутых аналогий. База данных (в общем понимании этого слова) это RDBMS с поддержкой ACID.

В противном случае, и ощипанный петух будет человеком.

Вопрос поставлен неправильно.
Чтоб оптимизировать odbc - надо 100% знать что именно он является узким местом. Я бы начал с анализа исполнения и извлечения данных локально на сервере. ДБА здесь поможет. И если ваша задаче связана с ETL - почитайте про техники. Может экспорт в csv файл с загрузкой в с++ приложение будет быстрее. Может репликация бд или миграция.

Сервер БД рассматривается как черный ящик. Очень похожий на HTTP-сервер. Основная задача которого - интерактировать с протоколом запроса-ответа на языке SQL. И все данные которые вы из него получаете - можно получить так. Выводить на консоль там некуда т.к. нет консоли (обычно). А отвественные DBA обычно никого не подпускают к SSH консоли чтоб не было проблем с безопасностью и с нагрузкой. Так делают в ентерпрайзе и на предприятиях.

Но если вы установили БД себе локально - то можете конечно писать себе отчоты на локальную ФС. В Оракле есть пакет UTL_FILE. Писать в текстовую консоль я не советую. Этот output может быть блокирующим и производительность вашей БД упадет т.к. она будет ОЖИДАТЬ прокрутки экрана например.

Альтернативой можно рассмотреть просто использование утилит экспорта exp/expdp/dump/pg_dump e.t.c. Или вообще любых консольных клиентов. Но возможно вопрос автора лежит в плоскости отладки хранимых процедур например? Здесь все еще сложнее и надо смотреть конкретную DBMS.

Да можно слить 2 таблицы в одну.

Это называется денормализация.

Все способы - по своему правильные. Но на развитие этой мысли мне не хватит формата сообщения. Грубо говоря. Если твои данные не будут обновляться. И не будет аномалий обновления. То спокойно храни все в 1 таблице.

Вопрос в перспективе тянет на экспертную систему по выбору БД.

При данной постановке - можно брать любую документно-ориентированную. Все одинаково подходят.
Но если основной контент (80% берем по Паретто) это файлы - то можно брать Amazon S3, в дальнейшем с перспективой трансформировать это в DynamoDb если понадобятся транзакции или в Amazon Document Db (он же Mongo) если понадобится тонкая работа с атрибутами документов (или файлов).

Автор должен понять что в это вопросе нет единого правильного решения. Есть просто некая сравнительная табличка где есть набор фичей с одной стороны и набор DBMS с другой и нет такого покрытия которое бы закрыло ВСЕ фичи.

Если автору нужно хранить данные измерений (графики) в режиме append-only, то можно посмотреть в сторону InfluxDB.

Делаешь две БД. И пишешь в одну все записи удовлетворяющие HASHCODE(primaryKeys, 2) == 0
а во вторую БД HASHCODE(primaryKeys, 2) == 1. При запросах соотв. делаешь запрос в две БД и объединяешь результат.

Самым быстрым являются хешмапы в памяти приложения. Но вопрос на самом деле более сложный. Как только нам нужно делать join 2-3 таблиц тогда - работает сложная квантовая механика оптимизатора и вариантов быстроты становится целая матрица.

Зависит от ценности этой информации. Если эту схему рассматривать как историю - то ничего удалять не надо. Просто перепишите ваши отчоты чтоб они делали GROUP BY и DISTINCT и просто игнорировали дубли.

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

Удалять - советчиков много. Но все они - безотвественные и если вам не стоит слушать советов по чистке данных именно здесь в тостере то вы рискуете какраз потерять нужные данные.

Автор очень быстро отбросил Postgres. Но я хочу спросить были ли исследованы все возможности? Например TimescaleDb.

База данных в таких случаях не подходит. Она не умеет индексировать "по ключевым словам". И выражения с LIKE обычно дают плохие планы выполнения т.к. искомое стоит в середине строки. Классический базёвый индекс в таких случаях не работает. Можно поробовать оффлайновый индекс по товарам с использованием Apache Lucene. Но это потребует определённых усилий по подготовке и актуализации такого индекса. Грубо говоря его надо постоянно синхронизировать по новым товарам.

Вокруг этого термина очень много спекуляций. Для БД в общем случае объектность не нужна т.к. базовый SQL Ansi-92 объектность не поддерживает и поэтому толку от объектности на уровне запросов - никакого. Вообще объектность это - метафора. Она очень часто завязана на языке и фреймворке и среде разработки (например Java-Spring). Само по себе наследование таблиц или типов например в Oracle поддерживается (CREATE TYPE .. UNDER) но % использования этой опции в продуктиве численно равен нулю. И вообще. Чтобы наследование было полноценным - нужен RTTI и рефлексия а для реляционных БД это означает что каждый data-row должен нести в себе информацию о типе. Это слишком накладно в общем случае. И для классической линейки RDBMS никто это не сделал.