Хочу быть Agile коучем. Как говориться "… не мешки ворочать". А если в срок не успеваем, то всегда можно напрячь программистов и заставить работать круглосуточно )
Ну, это конечно меня вообще убивает: «repeatable read — uses snapshot per transaction for plain SELECT. See the “read committed” for SELECT FOR UPDATE, INSERT, UPDATE, DELETE. Next-key locking provides repeatable reads for SELECT FOR UPDATE, INSERT, UPDATE, DELETE. Next key locks are implemented by locking index entries and the lock implies that the gap to the previous index entry is also locked. The use of “current” rather than “consistent” reads for INSERT, UPDATE, DELETE can cause surprises. For example a transaction might do SELECT to figure out what rows might match and then when an UPDATE is done with the same WHERE clause the matched rows can differ.»
Двигатель набирает обороты все быстрее и быстрее – педаль газа выжата до отказа, но почему-то вид из окна не меняется...
Прям про мой УАЗ написано )) А если серьезно, я тоже настроен весьма скептически по отношению к светлому будущему, к которому нас ведут технологии. Хотя вот некоторые редкие сервисы, типа Яндекс такси, действительно работают и делают мир лучше ) Не сочтите за рекламу )
Давно такой херни не читал. Вот зачем JS-программисту знать про, скажем, TCP/IP? Пусть лучше качественно делает свою работу. Ну а если у него возникнут проблемы при программировании веб-сокетов, ну ничего страшного, я ему помогу, разберемся вместе. Тоже самое и во всем остальном. Короче, уважаемый автор, чаще общайтесь с людьми, меньше раскладывайте пасьянс.
Ты имеешь ввиду READ-COMMITTED по-умолчанию? При READ-COMMITTED мы можем прочитать данные согласовано только в пределах одного SQL запроса. А если запроса два — то между ними другая транзакция может навтыкать данные. И к каким последствиям это может привести — тяжело предсказать. Например в первом запросе извлек айдишники, а во втором запросе пытаешься подтянуть по ним данные (типа такой программный join осуществляешь). И всё, бабах. По некоторым айдишникам ниче не подтянулось, NullPointerException. Кто-то удалили эти записи между запросами. Придется предусматривать в коде этот случай.
Насчет innodb_flush_log_at_trx_commit=0 может и перебор, если в датацентре свет отключат. А насчет innodb_locks_unsafe_for_binlog всё верно. Я конечно понимаю, что REPEATABLE-READ ведет к дедлокам и тормозам, но, блин, это так удобно, это как SERIALIZABLE в PostgreSQL.
Я бы поставил innodb_locks_unsafe_for_binlog=false чтобы режим REPEATABLE-READ нормально работал. А также поставил бы innodb_flush_log_at_trx_commit=0.
Я бы поставил innodb_locks_unsafe_for_binlog=false чтобы режим REPEATABLE-READ нормально работал. А также поставил бы innodb_flush_log_at_trx_commit=0.
На многих гос-проектах всегда требуют сделать защиту от потери данных, если с ЦОДом что-то случится и синхронная репликация, даже не обязательно мульти-мастер, оч. проста и удобна. Это конечно глупо гонять данные на другой ЦОД и ждать ответа, но если по нагрузке проблем нет, то юзать можно.
А есть ли для postgres master-master репликация простая в настройке? В интернете часто встречаю статьи про танцы с бубнами. Причем желательно вставлять данные в оба мастера и чтобы это работало между 2-мя ЦОДами, пусть не быстро но стабильно.
Ну и еще вопрос в догонку ) Вот есть у меня несколько таблиц (штук 5) которые джоинятся чтобы получить итоговый результат. В одной из таблиц штук 15 столбцов и по каждому столбцу индекс (т.к. хотим сортировать по любому столбцу). Теперь вопрос: сколько максимально записей можно хранить в такой таблице на хорошем выделенном серваке с ssd дисками, 256г оперативки и т.д. Чтобы база хоть как-то шевелилась. Ну приблизительно порядок хотябы. Подойдет ответ в стиле «более 100 млн не рекомендуется, возможны тормоза...». Спасибо!
"Интересно, где люди берут пластинки?" На озоне конечно покупают. Как и всю остальную технику.
Ну и еще вопрос в догонку ) Вот есть у меня несколько таблиц (штук 5) которые джоинятся чтобы получить итоговый результат. В одной из таблиц штук 15 столбцов и по каждому столбцу индекс (т.к. хотим сортировать по любому столбцу). Теперь вопрос: сколько максимально записей можно хранить в такой таблице на хорошем выделенном серваке с ssd дисками, 256г оперативки и т.д. Чтобы база хоть как-то шевелилась. Ну приблизительно порядок хотябы. Подойдет ответ в стиле «более 100 млн не рекомендуется, возможны тормоза...». Спасибо!