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

Question

Я хочу построить веб-сайт / приложение.Модель класса составляет около 100 объектов и не особенно сложна.

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

IЯ хотел бы использовать готовый каркас персистентности, а не писать свой собственный JDBC для доступа к базе данных.

У меня нет выбора, кроме как использовать реляционную базу данных.

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

Любые предложения по поводу того, какую среду хранения мне следует использовать?

ОБНОВЛЕНИЕ: Спасибо всем.Я думаю, что в этом случае способность передавать код в SQL является козырной.Вы можете сделать некоторые настройки параллелизма, если у вас есть доступ к нему.Хотя я согласен, у вас есть доступ к нему и в hibernate / jpa, это исключение, а не правило.myBatis также является более легким, менее "волшебным" видом структуры персистентности.Более того, из соображений производительности и масштабирования я не думаю, что было бы разумно использовать слишком много внешних ключей, когда коллекции управляются средой постоянства, поэтому я, вероятно, в любом случае не буду использовать эту возможность в hibernate.Это позволит мне при необходимости осколить БД.Я также думаю, что myBatis, вероятно, является более простой средой персистентности, которую можно освоить с первого раза.AFAIK, у этого нет прозрачного постоянства например.Ваши ответы подтвердили, что не существует другой стабильной структуры, которая бы больше соответствовала этим требованиям.

Answer 1

Если вам нужен оптимизированный вручную SQL, тогда я предлагаю myBatis (ранее известный как iBatis). Он обрабатывает механику JDBC для вас, а также отображение столбцов объектов, используя рукописный SQL, который вы ему предоставите.

То, что он не сделает , сделает для вас объектно-реляционное отображение (то есть автоматическая обработка ассоциаций и коллекций). Если это для вас более важно, то реализация JPA, такая как EclipseLink или Hibernate, является очевидным выбором. Они также могут обрабатывать пользовательский SQL, но это сложнее, чем с myBatis.

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

Answer 2

Я могу немного опоздать с вашим решением, но я думаю, что это может быть вариантом для будущих соображений.Я согласен с Qwerky в том, что кэширование на уровне абстракции данных (т. Е. ORM или другой платформе) переоценено.Большинство современных СУБД очень быстро работают со своими собственными внутренними кешами, поэтому обычно настройка производительности - это скорее работа DBA, чем разработка.Кроме того, плохо настроенные кэши быстро превращаются в кошмар производительности.

Я создал jOOQ в качестве структуры абстракции базы данных, которая старается оставаться очень близко к самому SQL, не помещая намного больше абстракции в началоJDBC, кроме объектно-ориентированных типов безопасных запросов, построенных из свободного API.jOOQ не скрывает никаких реляционных фактов из вашего кода Java, поэтому вы полностью контролируете используемый SQL.

http://www.jooq.org

Answer 3

Беспокойтесь о своей инфраструктуре и избегайте проектирования в узких местах, а не в рамках.

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

Answer 4

Если вы прочитаете это Учебное пособие по Hibernate (более 140 статей), вы обнаружите, что Hibernate можно использовать в качестве высокопроизводительной библиотеки доступа к данным по следующим причинам, которые также описаны в этот пример главы High-Performance Java Persistence :

• генераторы расширенных идентификаторов (hi / lo, pooled, pooled-lo)
• прозрачная готовая выписка из пакета
• высокосогласованные стратегии параллелизма для кэша на уровне объекта
• оптимистическая блокировка без версии (например, OptimisticLockType.ALL, OptimisticLockType.DIRTY)
• поддержка мультитенанса

Answer 5

как насчет персистентности, где rdbms не требуется, выделенного высокоскоростного, высоконадежного и высококонкурентного постоянного хранилища в модели класса Collections? Oracle (Sleycat) Berkeley DB был очень близок, но, к сожалению, сталкивается с проблемами блокировки показа-стопора с высокой степенью параллелизма.

Answer 6

Первым и очевидным выбором будет JPA или Hibernate , из которого он был получен.