Вы знаете сколько сейчас автоматических сеошных агрегаторов? и все они снимают позиции, покупают ссылки и крутят ПФы. Это судя по всему просто ещё один такой же.
Минимальным количество накладных расходов и предсказуемым поведением. Для одной из задач, где я и начал использовать тарантул, данные легко уместились в 6гб оперативки, а вот Redis пробил порог в 20гб и продолжал расти, так и не вставив всех данных.
А зачем при уровне изоляции read commited накапливать версии?? И откуда у вас информация что MySQL блокировочник? вы можете легко проверить свои домыслы установив mysql и открыв 2-е сессии.
Мы говорим про InnoDB. В MyIsam совсем нет транзакций.
Вы можете легко проверить что ошибаетесь :) открываете одну транзакцию с REPETABLE READ берёте 1-у запись из таблицы. В другой транзакции делаете вставку в эту таблицу, коммит и затем в первой делаете чтение последней записи из таблицы.
Таблица в первой транзакции не изменилась. На практике при большом количестве длинных транзакций и определённой модификации данны, БД просто влипает в селектах при REPETABLE READ, т.к. фиксируется версия любой таблицы задетой в транзакции. Транзакция закрывается в конце транзакции, у нас например OpenSessionInView что делает все операции во время одного HTTP запроса одной транзакцией.
2-ка нарушает D пусть и на 1 секунду, что касаемо I то если верить английской вики это
Isolation property ensures that the concurrent execution of transactions results in a system state that could have been obtained if transactions are executed serially i.e. one after the other.
Под это определение кмк только Serializable. A Repeatable reads и Read committed по сути на равных. У первого phantom reads у второго non-repeatable reads :)
Да, т.к. для большинства задач REPEATABLE READ не нужен. Скорее его удобно включать непосредственно в транзакции требующей такой уровень изолированности. Но ACID READ COMMITTED не нарушает.
Если не трудно, расскажите, в чём была проблема с флагами
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
Они обычно создают нагрузку на процессор, но держат память в норме. Проверено на порядка 12-16ГБ оперативной памяти.
Из собственного опыта.
Вначале лучше, чтобы человек вам кратко и доступно рассказала, что именно он делал на предыдушей работе (или просто умеет делать). Не в стиле «да мы там навернули абстрактную систему работающую с любой БД, которая если надо...», а именно какие он ЛИЧНО решал задачи и за что ОН ЛИЧНО ОТВЕЧАЛ.
Потом рекомендую предложить задачу, сложную не с олимпиадно-алгоритмеческой стороны, а со стороны умения человека понять задачу и составить список действий, которые необходимо сделать, чтобы реализовать поставленную задачу. Как правило у многих каша в голове именно в этой части, вроде и задача понятна, а что делать они не знают, и начинается разработка абстрактных систем несущих сомнительную пользу. Обычно выбирается задача, уже решаемая, или решённая в этой компании, предлагается придумать релизацию, затем грабли возможные по пути. Потом вы предлагаете свои грабли и смотрите как будет меняться уже описанная система.
Если вам помог мой пост, могу описать более подробно и с примерами.
Вы можете легко проверить что ошибаетесь :) открываете одну транзакцию с REPETABLE READ берёте 1-у запись из таблицы. В другой транзакции делаете вставку в эту таблицу, коммит и затем в первой делаете чтение последней записи из таблицы.
Таблица в первой транзакции не изменилась. На практике при большом количестве длинных транзакций и определённой модификации данны, БД просто влипает в селектах при REPETABLE READ, т.к. фиксируется версия любой таблицы задетой в транзакции. Транзакция закрывается в конце транзакции, у нас например OpenSessionInView что делает все операции во время одного HTTP запроса одной транзакцией.
Isolation property ensures that the concurrent execution of transactions results in a system state that could have been obtained if transactions are executed serially i.e. one after the other.
Под это определение кмк только Serializable. A Repeatable reads и Read committed по сути на равных. У первого phantom reads у второго non-repeatable reads :)
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
Они обычно создают нагрузку на процессор, но держат память в норме. Проверено на порядка 12-16ГБ оперативной памяти.
Вначале лучше, чтобы человек вам кратко и доступно рассказала, что именно он делал на предыдушей работе (или просто умеет делать). Не в стиле «да мы там навернули абстрактную систему работающую с любой БД, которая если надо...», а именно какие он ЛИЧНО решал задачи и за что ОН ЛИЧНО ОТВЕЧАЛ.
Потом рекомендую предложить задачу, сложную не с олимпиадно-алгоритмеческой стороны, а со стороны умения человека понять задачу и составить список действий, которые необходимо сделать, чтобы реализовать поставленную задачу. Как правило у многих каша в голове именно в этой части, вроде и задача понятна, а что делать они не знают, и начинается разработка абстрактных систем несущих сомнительную пользу. Обычно выбирается задача, уже решаемая, или решённая в этой компании, предлагается придумать релизацию, затем грабли возможные по пути. Потом вы предлагаете свои грабли и смотрите как будет меняться уже описанная система.
Если вам помог мой пост, могу описать более подробно и с примерами.