Невероятный кошмар базы данных MySQL

Таблица 1: Все, включая раковину. Даты в неправильном формате (год последний, поэтому вы не можете отсортировать по этому столбцу), числа, хранящиеся в виде VARCHAR, полные адреса в столбце "улица", имя и фамилия в столбце имени, город в столбце фамилии, неполные адреса, строки, которые обновить предшествующие строки, перемещая данные из одного поля в другое на основе некоторого набора правил, которые изменились за эти годы, дублирующих записей, неполных записей, записей мусора... вы называете это... о, и, конечно, не TIMESTAMP или PRIMARY КЛЮЧЕВАЯ колонка в поле зрения.

Таблица 2: Любая надежда на нормализацию исчезла из окна после взлома этого ребенка. У нас есть строки для каждой записи И обновления строк в первой таблице. Таким образом, дубликаты, как будто нет завтрашнего дня (стоит 800 МБ), и столбцы, такие как Phone1 Phone2 Phone3 Phone4... Phone15 (они не называются телефонными. Я использую это для иллюстрации) Ключ foriegn... ну, предположим. Есть три кандидата в зависимости от того, какие данные были в строке в таблице1

Таблица 3: Может ли быть еще хуже. О да. "Внешний ключ - это комбинация столбцов VARCHAR, состоящая из черточек, точек, цифр и букв! Если это не обеспечивает совпадение (что часто бывает), то второй столбец аналогичного кода продукта должен. Столбцы, имена которых содержат НИКАКОЙ корреляции с данными внутри них, а также обязательным Phone1 Phone2 Phone3 Phone4... Phone 15. Есть столбцы, дублированные из таблицы Table1, а столбца TIMESTAMP или PRIMARY KEY не видно.

Таблица 4: была описана как работа в процессе и может быть изменена в любой момент. Это существенно похоже на других.

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

Первоначально я разработал четырехэтапный перевод Таблицы 1, добавив ПЕРВИЧНЫЙ КЛЮЧ и преобразовав все даты в сортируемый формат. Затем еще пара шагов запросов, которые возвращали отфильтрованные данные, пока у меня не было Table1, где я мог бы использовать его для извлечения из других таблиц, чтобы сформировать композит. После нескольких недель работы я довел это до одного шага, используя некоторые приемы. Так что теперь я могу указать моему приложению на беспорядок и вытащить красивую чистую таблицу составных данных. К счастью, мне нужен только один из телефонных номеров для моих целей, поэтому нормализация моей таблицы не является проблемой.

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

Поскольку существующие строки в любой из таблиц могут быть изменены, а столбцы TIMESTAMP ON UPDATE отсутствуют, мне придется обратиться к журналам, чтобы узнать, что произошло. Конечно, это предполагает наличие двоичного журнала, которого нет!

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

Ситуация немного деликатная, потому что у них есть ценная информация, которую моя компания очень хочет. Я был послан высшим руководством крупной корпорации (вы знаете, как они), чтобы "сделать это".

Я не могу придумать другого способа обработки ночных обновлений, кроме анализа файла журнала bin другим приложением, чтобы выяснить, что они сделали с этой базой данных в течение дня, и затем соответствующим образом скомпоновать мою таблицу. Мне действительно нужно только взглянуть на их таблицу1, чтобы понять, что делать с моим столом. Другие таблицы просто предоставляют поля для очистки записи. (Использование MASTER SLAVE не поможет, потому что у меня будет дубликат беспорядка.)

Альтернативой является создание уникального хеша для каждой строки их таблицы1 и построение хеш-таблицы. Затем я каждую ночь просматривал ВСЮ базу данных, проверяя, совпадают ли хэши. Если они этого не делают, я бы прочитал эту запись и проверил, существует ли она в моей базе данных, если это произойдет, я бы обновил ее в своей базе данных, если нет, то это будет новая запись, и я вставлю ее. Это уродливо и не быстро, но синтаксический анализ двоичного файла журнала тоже не очень приятен.

Я написал это, чтобы помочь понять проблему. частое обращение к кому-то другому помогает прояснить проблему, делая решение более очевидным. В этом случае у меня просто больше головной боли!

Ваши мысли будут с благодарностью.

4 ответа

Решение

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

Я не MySQL человек, так что это выходит из левого поля.

Но я думаю, что файлы журнала могут быть ответом.

К счастью, вам действительно нужно знать только 2 вещи из журнала.

Вам нужна запись /rowid, и вам нужна операция.

В большинстве БД, и я предполагаю, что MySQL, в каждой строке есть неявный столбец, такой как rowid или recordid, или что-то еще. Это внутренний номер строки, используемый базой данных. Это ваш "бесплатный" первичный ключ.

Далее вам нужна операция. Примечательно, будет ли это операция вставки, обновления или удаления строки.

Вы объединяете всю эту информацию во времени, а затем проходите через нее.

Для каждой вставки / обновления вы выбираете строку из исходной БД и вставляете / обновляете эту строку в вашей целевой БД. Если это удаление, то вы удалите строку.

Вам не важны значения полей, они просто не важны. Сделайте весь ряд.

Надеюсь, вам не нужно "разбирать" двоичные файлы журналов, MySQL уже должен иметь подпрограммы для этого, вам просто нужно найти и выяснить, как их использовать (может даже быть какая-то удобная утилита "dump log", которую вы могли бы использовать).

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

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

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

Возможно, вы сможете использовать инструмент mk-table-sync от maatkit для синхронизации промежуточной базы данных (в конце концов, ваша база данных очень мала). Это будет "дублировать беспорядок"

Затем вы могли бы написать что-то, что после синхронизации выполняет различные запросы, чтобы сгенерировать набор более вменяемых таблиц, о которых вы затем сможете сообщить.

Я полагаю, что это можно делать ежедневно без проблем с производительностью.

Выполнение всего этого на другом сервере позволит избежать влияния на исходную базу данных.

Единственная проблема, которую я вижу, состоит в том, что некоторые таблицы не имеют первичных ключей.

Другие вопросы по тегам