nemo3001
Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
relictus
netrebos
egor23
Ну вот наконец-то выбрал время, чтобы рассмотреть влияние на возможность снижения количества дисковых операций настройки SatMap, названной "Размер кэша БД SQLite", значение по умолчанию - 2000 страниц, прочитал конечно обсуждение этой настройки на форуме в мае, после появления версии SatMap v2.3.7.
Хотелось понять, как связана эта настройка с настройкой количества вставок в БД до завершения транзакции и как повлияет на количество дисковых операций различный размер кэша БД SQLite в зависимости от разного количества вставок в БД.
Кратко напишу, как я себе представляю использование программой кэша БД SQLite и какие выводы можно сделать из этого.
Стоит сказать, что термином "кэш" (cache) можно назвать самые разные вещи (даже наличные деньги так называют, только это уже "cash"). Переведу в нашем случае это слово как "место хранения, хранилище" и постараюсь хотя бы по-разному именовать разные виды кэша, которые используются программой SatMap - временные, постоянные, на жестком диске, в ОЗУ.
Ну, например,
1) "кэш SatMap" - это БД SQLite, постоянное хранилище тайлов и связанной с ними информации на жестком диске.
2) "Журнал" - это временное хранилище тайлов на жестком диске до передачи их в кэш SatMap.
3) "Кэш БД SQLite", указанный в настройках программы, это временное хранилище информации в ОЗУ компьютера, используемое "движком" SQLite (то есть встроенными функциями SQLIte) для работы с БД SQLite.
А еще в настройках SatMap есть "Внутренний кэш", но это уже временное хранилище тайлов в ОЗУ, предназначенное для ускорения просмотра карты на экране и не имеющее прямого отношения к закачке/сохранению тайлов.
В упрощенном представлении пути тайла из интернета в кэш SatMap, как "закачка тайла -> журнал => кэш SatMap", на самом деле стрелки отмечают места, где вероятно и используется кэш БД SQLite.
На первом этапе, после получения тайлов из интернета они вероятно не записываются сразу в журнал поштучно, а сначала накапливаются в кэше БД SQLite в ОЗУ и записываются в журнал одной порцией либо при заполнении этого кэша до предела, указанного в настройке программы, либо при выполнении команды в программе о завершении транзакции (напомню, что в этот момент вся информация из журнала копируется в кэш SatMap и журнал после этого очищается или удаляется).
Во всяком случае вроде так описывал ситуацию relictus по документации к SQLite:
Цитата:| все скачанные тайлы будут находиться в области памяти, зарезервированной движком SQLite |
Используется ли этот кэш БД SQLite на втором этапе, при копировании информации из журнала в кэш SatMap, конечно не ясно, но тоже вероятно. Чем копировать из журнала по одной записи, вроде бы быстрее прочитать группу записей в ОЗУ и записать их оттуда в кэш SatMap.
Этот вопрос хорошо бы еще уточнить, потому что при недозаполненном кэше БД SQLite и завершении транзакции вроде бы нет необходимости записывать сначала скачанные тайлы в журнал, потом читать их в ОЗУ и снова записывать их же в кэш SatMap, а тем не менее в прошлом тесте мы видели, что дисковые операции с журналом происходят активно.
Журнал транзакций нужен для надежной, с возможностью отката при аварии, записи тайлов в кэш SatMap. Если настройка размера кэша БД SQLite здесь влияет на работу, то видимо надо добиваться, чтобы весь журнал входил целиком в кэш БД SQLite, иначе потребуется считывать его несколько раз порциями. А если настраиваемый размер кэша БД SQLite здесь не участвует, то достаточно будет подробно рассмотреть работу программы только на первом этапе - от закачки тайлов и накопления их в ОЗУ до копирования тайлов в журнал.
Впрочем, теперь уже несложно описать требования к настройкам программы для первого этапа получения тайлов - от интернета до журнала.
Суммарный размер тайлов до завершения транзакции должен быть меньше указанного в настройках размера кэша БД SQLite, тогда все закачанные тайлы (в количестве, указанном в настройке "количество вставок в БД") будут записаны из ОЗУ в журнал за один раз.
Иначе же тайлы все равно будут записываться в журнал порциями, но меньшего размера, в соответствии с указанным в настройках размером кэша БД SQLite. Это тоже достаточно безопасно по нагрузке на жесткий диск, запись будет производиться не по одному тайлу, просто порции эти будут поменьше, чем мы установим в настройке "количество вставок в БД".
Например, мы установили "количество вставок в БД" по 1000 штук, а в кэш БД SQLite вошло только 600 тайлов. Тогда первой порцией в журнал запишется 600 тайлов, второй порцией - оставшиеся 400 и все, поступит команда завершения транзакции. Вместо однократного обращения к жесткому диску будет двукратное, но с меньшим объемом информации за 1 раз.
Вот и все, никакой чрезвычайной нагрузки на жесткий диск не произойдет, даже если мы неверно установили размер кэша БД SQLite и указанное нами "количество вставок в БД" не вместилось в этот кэш.
Осталось подсчитать, сколько же "вставок в БД" поместится при указанном в настройках по умолчанию размере кэша БД SQLite в 2000 страниц.
relictus уже писал, что размер 1 страницы кэша БД SQLite - 16 кб и общий его размер по умолчанию составляет в программе 16*2000= 32 мегабайта.
Размер 1 тайла изменяется в широких пределах, от 1-2 до 30 кб и возможно больше. Например, тайл x=1654&y=635&z=11 оказался размером 29135 байт, но средний размер 16 тыс соседних с ним тайлов уже оказался 18000 байт.
Для максимальной оценки возьмем закачку самых больших по размеру тайлов. Тогда в кэш БД SQLite по умолчанию войдет примерно 1000 таких больших тайлов, а реально, с учетом среднего их размера - в 2 раза больше.
Я первоначально рекомендовал "количество вставок в БД" в 20 шт, а в тесте пробовал цифры в 50 и 100 шт. Мы помним, что rex писал об использовании им количества вставок в 128 шт, egor23 говорил, что использует 1000 вставок в БД до завершения транзакции.
Как теперь видно, и 20 и 1000 вставок в БД спокойно, с большим запасом вмещаются в кэш БД SQLite, установленный в программе по умолчанию.
А значит не стоит опасаться и "настройки времени задержки между вставками в кэш SatMap прямо в секундах" (со значением по умолчанию в 30 сек) вместо или вместе с существующей сейчас настройкой "количество вставок в БД".
Со скоростью 10 тайлов в сек (где бы еще взять такую скорость  ) пользователь будет заполнять кэш БД SQLite в течение 100-200 секунд, то есть целых полторы-три минуты, а реально - так конечно больше. А если он при этом забудет увеличить размер кэша БД SQLite, то просто раз в несколько минут этот кэш все равно будет записываться в журнал. И никакой проблемы в этом видимо нет.
Так что, если конечно хватило сил дочитать до конца все это безобразие, я как смог попытался развеять пессимизм фраз:
Цитата:| возникают вопросы, от времени зависят текущие две настройки, и в частности кол-во страниц. |
Цитата: Ну да, это я как-то упустил из виду...
Сразу что-то отпала охота реализовывать временнУю задержку между вставками |
Вывод из всего этого получился очень простой.
1. Имеющаяся сейчас в программе по умолчанию настройка размера кэша БД SQLite в 2000 страниц обеспечивает безопасную для жесткого диска закачку тайлов при большом диапазоне возможных настроек количества вставок в БД до завершения транзакции, от, скажем, 20 вставок и больше, вплоть до 1000 вставок в БД.
2. Добавление настройки времени задержки между вставками в кэш SatMap прямо в секундах, что позволило бы автоматически регулировать нагрузку на жесткий диск для пользователей с самыми разными скоростями доступа в интернет, никак не ухудшает режимы работы жесткого диска, если установить ее значение не меньше 20-30 сек.
|
. Это еще один оригинальный прожект. Скорость закачки не постоянна и геморрой будет еще тот, а пользы пшик. Просто установи по дефолту любое из понравившихся тебе значений количества вставок в диапазоне 16 - 128. Для защиты диска начинающего пользователя вполне достаточно, а опытный все равно под свой интернет и свои задачи сам все подстроит. 
Так и осталось висеть в пустоте