Мейнфреймы были и остаются очень быстрыми для определенных случаев использования, поэтому первая часть не предполагает, что мэйнфрейм = плохой. Сказав это, они могут быть очень дорогими для поддержания, и особенно с устаревшими приложениями навыки начинают испаряться.
Если вам действительно нужна иерархическая база данных, одним из действительных вариантов было бы модернизировать ваше приложение, но сохранить IMS в ядре. IMS - отличная иерархическая база данных, и я не думаю, что IBM собирается в EOL IMS в ближайшее время, так есть ли настоящая причина пойти в иерархическую базу данных, которая не IMS? Быстрый визит на их веб-сайт дал мне впечатление, что они будут радовать продукт, если они думают, что вы собираетесь перейти на конкурирующий продукт, поэтому, если деньги являются проблемой, то, возможно, ответ заключается в том, чтобы просто попросить IBM о скидке на продукт, который вы «Я уже доволен. В этом техническом документе (ftp://public.dhe.ibm.com/software/data/ims/pdf/TCG2013015LI.pdf) говорится, что они подталкивают это как вариант, и, без сомнения, более поздние версии IMS имеют множество функций, которые могут быть недоступны в версии, которую вы используете (при условии, что вы не обновили ее до последний).
Я удивлен, что вы не можете получить производительность, которую хотите от Oracle, хотя система, над которой я сейчас работаю, имеет пару таблиц на отметке миллиарда, и у нас определенно нет 128 ядер, но мы получаем разумную производительность.
Мой первый вопрос заключается в том, действительно ли ваш консультант Oracle знал свои вещи. У меня были смешанные результаты, я думаю, как и любой навык, с которым люди могут обладать переменными навыками. Я часто нахожу, что, когда вы получаете проблемы с производительностью, это происходит потому, что люди имеют слишком нормализованную или чрезмерно обобщенную схему базы данных, поэтому вы перешли от высоко оптимизированной иерархической структуры в IMS, которая перемещается в очень абстрактную структуру в 3NF и которая умирает , Но иногда, если вы ставите эту иерархическую структуру в Oracle и допускаете только те же шаблоны доступа, которые были возможны в IMS, вы получите всю необходимую производительность.
Под этим я имею в виду, что если в IMS у вас были клиенты, у клиентов были заказы, а заказы имели строки заказов, то я думаю, это означает, что довольно трудно делать какие-либо обращения, не начиная с клиента. Это также часто означает, что у вас есть большие пакетные процессы, которые обрабатывают всех клиентов каждый день, чтобы узнать, какие заказы вам нужно сделать.
Итак, некоторые вещи здесь. Во-первых, если в Oracle вы должны были создать эту структуру, поэтому у меня есть идентификатор клиента, идентификатор клиента - это первый элемент первичного ключа заказов, а идентификатор клиента - идентификатор заказа - первые два элемента в первичный ключ строк заказа, а затем я использую идентификатор клиента в качестве ключа кластеризации и поместил идентификатор клиента в каждый индекс ... вероятно, все мои пути доступа на основе клиента будут очень быстрыми. Вы также можете разделить по идентификатору клиента и, при необходимости, запустить кластер Oracle RAC с каждым из этих разделов/диапазонов клиентов, эффективно выполняемых как отдельные базы данных на отдельной машине большего количества товаров (скажем, в двухъядерной машине = около 20 ядер).
Во-вторых, если раньше мне приходилось обрабатывать все мои записи раз в сутки, чтобы найти заказы, в которых кто-то должен был работать над ними, то в новом реляционном мире мне больше не нужно это делать, я просто нужно найти заказы со статусом «ожидающий» или что-то еще.Поэтому, возможно, Oracle не так быстро подходит для этой пакетной рабочей нагрузки, но если я изменю свою логику и сделаю индексированный запрос для отложенных ордеров, я снова смогу получить всю производительность, которую я хочу. Более того, возможно, я делаю order_status в ключе секционирования, поэтому мои «активные» записи находятся в одном разделе, а все старые заказы - в других разделах, а затем я помещаю этот раздел в массив с поддержкой SSD.
В-третьих, взгляните на свои устройства хранения данных. Проблемы с производительностью в базах данных - это неизменно проблемы ввода-вывода - либо слишком много IO (плохо оптимизированные запросы), либо ваша подсистема ввода-вывода не может идти в ногу с IO, что вам нужно делать. 128 ядер - это очень много вычислений, и я редко видел базу данных, которая вычисляется. Возможно, посмотрите на большой массив SSD, некоторые из них могут дать вам огромную пропускную способность ввода-вывода. Разумеется, если вы используете Oracle в массиве вращающегося диска RAID 5, ваша производительность, вероятно, будет сосать.
Последний случайный комментарий здесь - многие люди получают хорошие результаты с помощью SAP HANA - полной базы данных в памяти. Это действительно летает и специально предназначено для рабочих нагрузок, которые просто не будут работать достаточно быстро в других базах данных. Я готов поспорить, что SAP придет к вам бесплатно, если вы этого захотите.
Это слишком широкое решение - для этого может быть много причин. Тем не менее, я бы ожидал, что вы получите гораздо лучшую производительность из всех новых систем, которые вы пробовали, поскольку с течением времени методы внутренней оптимизации улучшаются. Подозреваю, что за миллиарды записей вы будете смотреть на осколки. – halfer