Есть ли особый способ управления постоянно растущей базой данных?

Question

Отказ от ответственности: я новичок в мире баз данных

Интересно: как вы решаете проблему постоянно растущего стола?

Я имею в виду, что я хотел бы знать "последний добавленный элемент", тогда я делаю

ВЫБРАТЬ * ИЗ планеты ИСТОРИЯ ГДЕ имя = "земля" ЗАКАЗАТЬ по дате DESC LIMIT 1;

Это кажется плохой идеей, потому что это займет все больше и больше времени по мере роста стола. Что мне приходит в голову, это «подготовить» дизайн базы данных к обычным будущим запросам. Для этого примера база данных может включать таблицу с одним полем и экземпляром:

+-----------------+
|table "lastAdded"|
+-----------------+
|     3242        |
+-----------------+

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

Звучит странно, но мне кажется хуже заказать 1 терабайт данных "просто чтобы знать, что является последним", что страннее

Answer 1

Упорядочение по индексированному столбцу делает такую ​​оптимизацию «под капотом» для вас.

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

Выполнение такой «оптимизации» самостоятельно может вызвать ряд других проблем:

1. Дублированные данные, которыеможет выйти из синхронизации
2. Ненужная сложность, если предположить, что в первую очередь не было проблем с производительностью
3. Сложнее решать реальные проблемы с производительностью, когда они возникают, потому что более сложный код / ​​запросы означаютРеорганизовать / оптимизировать сложнее

Контролировать свое приложение / БД, чтобы вы могли активно решать проблемы с производительностью, но не решать их, пока не узнаете, что есть проблема.Особенно, когда речь идет о БД, они построены так, чтобы быть максимально быстрыми;когда они не быстрые, это обычно происходит из-за того, что мы делаем, что глупо.

Answer 2

Я бы сделал это с отметками времени. Это также позволит вам разбить вашу базу данных, чтобы вы могли в конечном итоге удалить часть данных, которая превысила ваш предел «должны сохранять».

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

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