Какие подводные камни могут быть, если все PK и FK в базе будут созданы с указанием использования DESC-индекса?

Для быстрого select max(some_pk) ...

kvd, погоди. Это пока еще нормальные вопросы :-)

Симонов Денис, самодельный репликатор, написанный за один день "на коленке", чтобы реплицировать данные между "филиалами" и центральной базой, использует такие запросы. На очень больших таблицах (порядка миллиарда записей) начинаются тормоза. А если учесть, что данные должны реплицироваться каждые 10(!) секунд, то вообще все грустно... Можно было бы написать его по-нормальному или задействовать готовый, но уже нету времени, т.к. внедрение системы должно вот-вот должно начаться. Поэтому ищу наиболее быстрые решения.

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

Симонов Денис, да так и есть. Репликация была сделана методом, который первый пришел в голову. Таблицы логов хранят только инфу об update и delete. Информация о новых записях получается путем сравнения максимальных значений ключевых полей. В общем-то все работает без сбоев, но проверка на большой сгенерированной базе показала тормоза.

Так что в итоге? Внутренности репликатора обсудили. А что насчет вопроса в первом сообщении темы?

kdv, я тебе объяснил ситуацию. Я со всем согласен, но из-за недостатка времени меня интересуют очень быстрые решения. И самое простое решение в том, чтобы индексы по PK были убывающие (ну и соответственно по FK тоже, т.к. об этом предупреждается в документации). В этом случае max(pk) отрабатывает очень быстро.
Так вот, повторюсь: я не получу проблемы с такими индексам?

Для многопользовательской среды там все учтено. Проблем с max(id) быть не может. В каждый момент может быть только одна транзакция репликатора в базе.
Так что там с убывающими индексами для pk и fk? Может мне хоть кто-нибудь ответить?

Симонов Денис, да таблица одна на всех. И у нее есть id, максимальное значение которого сохраняется и используется репликатором. Но ней не хранятся данные о вставленных записях. Только об удаленных и измененных.

Dimitry Sibiryakov, я бы просто создал отдельный индекс, но для таблицы-миллиардника иметь два индекса по bigint-полю - это расточительство с точки зрения оптимальности импользования кэша :-)

Симонов Денис, ну во первых, работает это как я ожидаю. Это тебе не "эмуляция" генераторов через max(id)+1 :-)
А во вторых, у меня и так уже ожидаются две таблицы с заполнением более 500 млн. строк в год. Иметь еще одну гигантскую таблицу с логами мне не хочется. Хотя ее можно периодически подчищать, но сейчас из-за недостатка времени мне хочется иметь максимально простое решение.

fd00ch, я тоже надеюсь, что их нет. Но ответы в этом форуме заставили призадуматься... :-)

Симонов Денис, уже думал об этом. Это я сделаю в случае, если будут косяки или тормоза с убывающими индексами по pk.

Dimitry Sibiryakov, нет. max(id) не используется для генерации чего либо. Это всего-лишь способ получения информации для репликатора. И тестируется все это в многопользовательской среде. Если у тебя есть конкретные идеи, как это может не сработать - сообщай, буду вникать и думать )

Эх. Тема ушла далеко в оффтоп. Особенно радуют советы про гарантированные проблемы с max(id), с учетом того, что советчики не знают как оно там устроено. Сегодня попробую сменить направление у индексов для pk и fk.

kdv, максимально просто )

Только что попробовал pk и fk с убывающими индексами. Ничего не упало, диск с: не отформатировался, а за окном не пошёл зелёный снег, как можно было бы ожидать из ответов в этой теме... )

База с pk и fk с убывающими индексами за ночь немного заполнилась тестовыми данными. В итоге получилось не то, что я ожидал. Для примера запрос


(где 20000000000-24999999999 - диапазон pk, в котором создаёт свои записи филиал №2) на "непрогретой" базе выполняется 12 минут :( На прогретой- 0.3 сек, но это всё равно медленно. А ведь в таблице только 100 млн записей, что в 10 раз меньше наполнения за год.

В итоге переделал наподобие того, как советовал Симонов Денис:
create table t (
tablename char(31) not null,
source_db char(31) not null,
last_id bigint
)

Наверное на этом пока и успокоюсь :)

Вот блин, отказался от desc-индексов для pk в базе и рубль начал падать. Звиняйте )))