Когда я писал поиск, а он у меня собирается в отдельной таблице, то озадачился онлайн обновлением. Придумал несколько вариантов, но поскольку я не большой спец. по БД, то тумаю что они не оптимальны или можно придумать что нибудь другое. И так варианты:
Последний, и как мне кажется самый лучший. Создается некая таблица Update : id, id_osm, type char(1), action char(1), myTable1 bool, myTable2 bool … . В таблицы nodes, ways, relations вешаются триггеры на insert, update и delete которые при любом действии добавляют запись в таблицу update, т.е. получаем некий лог. А каждых 10мин, 30мин, 1час,… делается запрос на эту таблицу выбираются данные select * from update where not myTable1 дальше производятся нужные действия и в конце update myTable1=TRUE. А раз в день/неделю/месяц, будет запускаться утилизатор DELETE FROM update WHERE myTable1 and myTable2 …. Такая организация позволит подключать кучу таблиц/БД которые будут онлайн обновлятся, простым добавлением myTableN
Остальные уже забылись или бредовые
И так специалисты и не очень, что скажите по этой схеме или есть другие варианты. И вообще стоит ли закорачиваться с обновлением, или просто всегда делать с нуля и это будет всегда быстрее. Но блин, если например мировой поисковик, то он долго будет обновляться с нуля.
может лучше вместо myTable1, myTable2 - одно поле myTable с возможными значениями 1,2…n
на триггерах вставлять n записей или меньше если, например, изменения в таблице nodes не вызывают необходимости обновить некоторые из собственных таблиц
вместо “select * from update where not myTable1”
select * from update where myTable=1
вместо “update myTable1=TRUE”
update myTable1=0
вместо “DELETE FROM update WHERE myTable1 and myTable2”
DELETE FROM update WHERE myTable=0
Такая организация позволит подключать неограниченную кучу таблиц
не понял, в моем случае для обновления
tabl1/бд1 - update myTable1=TRUE
tabl2/бд2 - update myTable2=TRUE
т.е. независимость.
или в myTable будет типа бинарной маски, т.е. 1 для tabl1, 2 для tabl2, 4 для tabl3 ?
тогда тут возможны схлестывание двух скриптов, ибо будут оба менять одно поле на разные значение
под каждую таблицу своя запись: “на триггерах вставлять n записей или меньше если, например, изменения в таблице nodes не вызывают необходимости обновить некоторые из собственных таблиц”
для обновления независимо от записи/номератаблицы
update myTable=0
в myTable будет номер таблицы
В таблицы node, ways, relations добавляется поле updated_at, которое меняется триггерами в момент вставки/удаления и содержит время обновления данных.
Для отслеживаний удалений создается таблица deleted_entries с полями type, osm_id, deleted_at
Эта таблица заполняется тригеррами на удаление из node, ways, relations
С этим подходом не создаются лишние жирные записи на каждую обновленную (на удаленные создается одна запись) и мы всегда можем узнать когда что-то обновилось/добавилось/удалилось.
Дальше два варианта:
4а) Для каждой внутренней таблицы где-то храним глобальное время последнего обновления и по ней определяем какие записи обновились
В этом случае, если нет дополнительных допущений, то таблицу необходимо обновлять вместе с меткой в рамках одной транзакции, иначе можно что-то пропустить. И в этой транзакции практически наверняка вся таблица заблокируется.
Но поскольку исходные данные обновляются не всегда (вряд ли чаще, чем раз в день), то если мы уверены что процесс обновления внутренних таблиц не пересечется с обновлением исходных, то это требование необязательно.
4б) Для каждой записи внутренней таблицы храним время последнего обновления и по ней определяем обновилась ли эта запись
Поскольку здесь обновление может быть произведено на базе каждой отдельной записи, то можно разделить процесс обновления внутренней таблицы на много маленьких транзакций и таким образом избежать блокировки всей таблицы. Кроме того, можно обновлять данные в любом порядке, какой хочется, какие-то типы данных обновлять чаще/реже и так далее.
Но тут сложнее отслеживать вставки.
