Как модернизировать огромную унаследованную базу данных?

Question

У меня есть вопрос, просто ищу предложения здесь.

Итак, мое приложение «модернизирует» настольное приложение, преобразовав его в Интернет с помощью пользовательского интерфейса ICEFaces и серверной части, написанной на Java. Однако они хранят одну и ту же базу данных Oracle, которая в настоящее время насчитывает около 700-900 таблиц и, вероятно, миллиард записей в таблицах. В некоторых отдельных таблицах 250 миллионов строк, во многих - более 25 миллионов.

Излишне говорить, что база данных плохо масштабируется. В результате производительность приложения выглядит ужасно. Все будущие архитекторы / лица, принимающие решения, либо отказались, либо не желают перестраивать постоянство. Итак, в основном мы наносим новый слой краски на функциональное настольное приложение, которое в настоящее время удовлетворяет большинство потребностей пользователей и делает это относительно легко. Реальная производительность базы данных в настольном приложении сейчас довольно низкая. Быстродействие, о котором я говорил ранее, было связано не с базами данных (извините, я ошибся там). Мне трудно спать по ночам, думая о том, как плохо будет работать это приложение, и как трудно обычным пользователям выполнять свою работу.

Итак, мой вопрос: какие у меня есть варианты для смягчения этой надвигающейся катастрофы? Есть ли какой-нибудь промежуточный слой, который я могу поместить между базой данных и кодом Java, чтобы повысить производительность и в то же время сохранить структуру базы данных нетронутой? Кэширование, очевидно, является вариантом, но я не вижу в этом панацеи. Можно ли наложить слой NoSQL DB между ними или что-то в этом роде?

Answer 1

Я не понимаю, как совместить две вещи, которые вы сказали.

Излишне говорить, что база данных плохо масштабируется

и

в настоящее время удовлетворяет большинство потребностей пользователей и делает это относительно легко и быстро.

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

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

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

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

Answer 2

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

Администратор базы данных должен иметь возможность легко определить дополнительную нагрузку на базу данных из вашего приложения. Предполагая, что логика не изменилась, вряд ли она будет делать больше записей. Это может быть чтение или «болтание» (перемещение того же объема информации, но в меньших пакетах). Болтливые приложения могут использовать много ресурсов процессора. Многие архитекторы пытаются переместить обработку со слоя базы данных на уровень приложения, потому что «работа с базой данных стоит дорого», но на самом деле все ухудшает из-за издержек «туда-сюда».

PS.

Нет ничего плохого в том, что в таблице 250 миллионов строк. Обычно вы получаете доступ к таблице через индекс. Обычно есть 2 или 3 прыжка от вершины индекса к основанию (а затем еще один к таблице). У меня есть таблица с 20 миллионами строк с УРОВНЕМ 2 и таблица с более 120 миллионами строк с УРОВНЕМ 3 *.

Индексирование означает, что вы редко поражаете более чем небольшую часть своих блоков данных. Часто используемые индексные блоки (и блоки данных) кэшируются в памяти сервера базы данных. Администратор баз данных сможет увидеть, не слишком ли мала эта область памяти для рабочей нагрузки (т. Е. Много физического ввода-вывода).

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

Answer 3

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

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

Теперь есть способы улучшить производительность базы данных. Первое, что я хотел бы рассмотреть с базой данных такого размера, это разбить данные на части. Я также хотел бы рассмотреть возможность архивации старых данных в хранилище данных и составления большей части отчетов. Другими вещами, которые следует учитывать, будет улучшение ваших серверов до высокопроизводительных моделей, профилирование для поиска самых медленных запросов и индивидуальное их исправление, просмотр индексации, обновление статистики и индексов (не уверен, что вы это делаете в Oracle, я SLQ Сервер гал, но твой дбас бы знал). Есть несколько хороших книг по рефакторингу старых устаревших баз данных. Нижеследующее не является специфичным для базы данных. http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533/ref=sr_1_1?ie=UTF8&s=books&qid=1275577997&sr=8-1 Есть также несколько хороших книг по настройке производительности (ищите те, которые относятся к Oracle, то, что работает для SQL Server или mySQL, не то, что лучше для Oracle) Лично я получал бы их и читал их от корки до корки, прежде чем разрабатывать план того, как вы собираетесь исправить низкую производительность. Я бы также включил администраторов баз данных во все ваши планы, они знают то, что вы не делаете с базой данных, и почему некоторые вещи разработаны так, как они есть.

Answer 4

Таким образом, вы наносите новый слой краски на функциональное и быстрое настольное приложение, и тогда система работает медленно?

А потом вы говорите, что "нет необходимости говорить, что база данных плохо масштабируется"?

Я не понимаю. Я думаю, что что-то не так с вашим свежим слоем краски, а не с базой данных.

Answer 5

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

Стратегия используется Google в их большой базе данных, и они сообщили, что она значительно повышает производительность.

http://en.wikipedia.org/wiki/Bloom_filter

Удачи, работа над задачами, в которые ты не веришь, трудна.

Answer 6

База данных является частью приложения. Не считайте их отдельными, это не так.

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

Ваша система разработки предположительно не имеет такого большого количества данных, но имеет точно такую ​​же схему.

Чтобы выполнить тестирование производительности, вам понадобится система с тем же оборудованием и данными того же размера (с теми же данными, если это возможно), что и на производстве. Вы должны объяснить руководству, что тестирование производительности абсолютно необходимо, поскольку вы чувствуете, что приложение не будет работать.

Конечно, внесение изменений в схему (добавление / удаление индексов, разбиение таблиц и т. Д.) Может повлиять на другие части системы - которые вы должны рассматривать как части СИСТЕМЫ - и, следовательно, выполнить необходимое регрессионное тестирование и исправление.

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

Answer 7

Если база данных унаследована и огромна, тогда

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

2) Если проблема связана с производительностью, вероятно, можно внести множество изменений в оптимизацию базы данных без изменения интерфейса.

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

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

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

Answer 8

Способ «смягчить надвигающуюся катастрофу» состоит в том, чтобы делать то, что вы должны делать в любом случае. Если вы будете следовать передовым методам, боль от смены слоя персистентности на более позднем этапе будет минимальной.

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

Answer 9

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

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

Вы смотрели на Терракотовую ? У них есть кое-что для кэширования и масштабирования, которое может иметь отношение к вам.

Прими это как вызов!

Answer 10

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

Что касается того, что вы можете сделать с производительностью, это во многом зависит от модели использования. Кэширование может очень помочь в основном только для чтения баз данных. Даже с базой данных для чтения / записи, она все равно может быть благом, если правильно спроектирована. База данных NoSQL может помочь с большими объемами записи, но это также может быть больше проблем, чем стоит, если данные все равно окажутся в обычной базе данных.

В конце концов, все зависит от архитектуры вашего приложения и моделей использования.

Удачи!