MySQL Cluster (Master / Slave) и Hibernate

Question

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

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
    <property name="driverClassName" value="com.mysql.jdbc.Driver" />
    <property name="url" value="jdbc:mysql://localhost:3306/test" />
    <property name="username" value="root" />
    <property name="password" value="" />
</bean>


<bean id="hibernateProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
    <property name="properties">
    <props>
        <prop key="hibernate.hbm2ddl.auto">update</prop>
        <prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>
        ...
        </props>
    </property>
</bean>

<bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
    <property name="dataSource">
        <ref local="dataSource" />
    </property>
    <property name="hibernateProperties">
    <ref bean="hibernateProperties" />
    </property>
    <property name="mappingResources">
    <list>
        <value>...</value>
    </list>
    </property>
</bean>

<bean id="txManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
    <property name="dataSource" ref="dataSource" />
    <property name="sessionFactory" ref="sessionFactory" />
</bean>

Однако для производства существует вероятность использования либо кластеризации MySQL, либо репликации Master / Slave. Любая идея об изменении кода / конфигурации для этого?

Также быстрый вопрос ко всем - сколько транзакций в секунду может обрабатывать один экземпляр сервера MySQL на выделенном сервере?

Answer 1

Я работал над аналогичной проблемой, хотя Spring не участвовал. Мы разработали указатель на локальный экземпляр MySQL (у каждого разработчика был один на своем боксе), а производственная система представляла собой кольцо репликации Master / Slave. На самом деле мы пошли еще дальше и совместили сервер приложений с сервером базы данных, поэтому на уровне приложений и базы данных был кластер из четырех узлов.

Наше приложение работает в JBoss. Это было довольно легко, но у него была серьезная кластеризация на уровне сервера приложений. При этом мы смогли получить более 300 запросов в секунду, а иногда и около 1000 запросов в секунду (в зависимости от обработки приложения). База данных никогда не была узким местом - даже при таких скоростях мы редко видели, чтобы пул соединений превышал 5 соединений.

В обоих случаях (мой и ваш), поскольку URL JDBC указывает на локальный сервер, функциональной разницы с точки зрения приложения на самом деле нет. Мне пришлось играть в некоторые интересные игры по настройке с настройкой автоинкремента, чтобы предотвратить появление данных; если у вас есть только одна точка развертывания (и, следовательно, одна точка доступа к экземплярам (ам) MySQL), вам не нужно беспокоиться об этом.

Итак, без изменений кода и без изменений конфигурации. Это просто сработает. При стандартных условиях тот факт, что вы поддерживаете пару экземпляров Master / Slave или кластер, не будет иметь значения, поскольку вы, скорее всего, будете указывать либо на экземпляр Master, либо на экземпляр MySQL, стоящий перед кластером (в MySQL). кластер находится за одним или несколькими серверами базы данных, реплицирующими данные).

С какими нагрузками вы хотите справиться? В прошлом MySQL был протестирован при> 1000 TPS, но результаты, как правило, варьируются в зависимости от характеристик системы (память, ядра ЦП, скорость процессора), отзывчивости вашего приложения и одновременных потоков.

Answer 2

Включение репликации в MySQL никак не влияет на конфигурацию Hibernate, если источник данных, используемый Hibernate, подключается к master , что типично. Если вам также необходимо подключиться к ведомому устройству (для запросов), это другая конфигурация.

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