Сколько строк может содержать таблица SQLite, прежде чем запросы станут трудоемкими

Question

Я настраиваю простую базу данных SQLite для хранения показаний датчиков. Таблицы будут выглядеть примерно так:

sensors  
 - id (pk) 
 - name  
 - description
 - units  

sensor_readings  
 - id (pk)  
 - sensor_id (fk to sensors)  
 - value (actual sensor value stored here)
 - time (date/time the sensor sample was taken)

Приложение будет собирать около 100 000 показаний датчиков в месяц с 30 различных датчиков, и я хотел бы хранить все показания датчиков в БД как можно дольше.

Большинство запросов будет в форме

SELECT * FROM sensor_readings WHERE sensor_id = x AND time > y AND time < z

Этот запрос обычно возвращает около 100-1000 результатов.

Таким образом, вопрос в том, насколько большой может быть таблица sensor_readings до того, как вышеуказанный запрос станет слишком трудоемким (более пары секунд на стандартном ПК).

Я знаю, что одним из исправлений может быть создание отдельной таблицы sensor_readings для каждого датчика, но я бы хотел этого избежать, если в этом нет необходимости. Существуют ли другие способы оптимизации этой схемы БД?

Answer 1

Если вы собираетесь использовать time в запросах, стоит добавить к нему индекс. Это будет единственная оптимизация, которую я бы предложил, основываясь на вашей информации.

100 000 вставок в месяц равняются примерно 2,3 в минуту, поэтому другой индекс не будет слишком обременительным и ускорит ваши запросы. Я предполагаю, что это 100 000 вставок на все 30 датчиков, а не 100 000 для каждого датчика, но, даже если я ошибаюсь, 70 вставок в минуту все равно должно быть в порядке.

Если производительность становится проблемой, у вас есть возможность выгружать более старые данные в хронологическую таблицу (скажем, sensor_readings_old) и выполнять запросы только в неисторической таблице (sensor_readings).

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

Answer 2

Правильно ли вы устанавливаете индексы? Помимо этого и чтения http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html, единственный ответ - «вам придется измерять себя» - тем более что это будет сильно зависеть от аппаратного обеспечения и от того, используете ли вы базу данных в памяти или на диске, и если вы вставляете вставки в транзакции или нет.

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

Answer 3

Я знаю, что прихожу к этому поздно, но я подумал, что это может быть полезно для всех, кто приходит к этому вопросу позже:

SQLite, как правило, работает относительно быстро при чтении, если одновременно обслуживает только одно приложение / пользователя. Параллелизм и блокировка могут стать проблемой при одновременном обращении к нему нескольких пользователей или приложений, и более надежные базы данных, такие как MS SQL Server, обычно лучше работают в среде с высоким уровнем параллелизма.

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

Вы также можете обратить внимание на скорость записи. Вставка может быть быстрой, но фиксация медленная, поэтому вы, вероятно, захотите объединить несколько вставок в одну транзакцию перед выполнением фиксации. Это обсуждается здесь: http://www.sqlite.org/faq.html#q19

Answer 4

SQLite теперь поддерживает индексы R-дерева (http://www.sqlite.org/rtree.html), что идеально, если вы собираетесь выполнять много запросов во временном диапазоне.

Tom