Postgresql в убере
https://eng.uber.com/mysql-migration/
http://postgresql.nabble.com/Why-we-lost-Uber-as-a-user-td5913417.html
Занятное чтиво про заморочки MVCC и реализации индексов в postgresql.
Все бы это хорошо, но я не понимаю один момент - почему они сравнивают только физическую репликацию (передачу изменений в страницах БД) и репликацию передачей исполняемых запросов?
Есть же вариант "передавать логические изменения в во всех измененных записях в порядке их коммита". Т.е. в таком варианте проблемы с недетерминированным выполнением запросов отсутствуют, но размер передаваемых данных заметно меньше, чем в случае "передавать весь WAL".
http://postgresql.nabble.com/Why-we-lost-Uber-as-a-user-td5913417.html
Занятное чтиво про заморочки MVCC и реализации индексов в postgresql.
Все бы это хорошо, но я не понимаю один момент - почему они сравнивают только физическую репликацию (передачу изменений в страницах БД) и репликацию передачей исполняемых запросов?
Есть же вариант "передавать логические изменения в во всех измененных записях в порядке их коммита". Т.е. в таком варианте проблемы с недетерминированным выполнением запросов отсутствуют, но размер передаваемых данных заметно меньше, чем в случае "передавать весь WAL".
no subject
Depending on how it’s written, the code may implicitly have a database transaction that’s held open until after the email finishes sending. While it’s always bad form to let your code hold open database transactions while performing unrelated blocking I/O, the reality is that most engineers are not database experts and may not always understand this problem, especially when using an ORM that obscures low-level details like open transactions.
Первое выделенное вообще чудесно. Я не столь давно встретил код на C# и EntityFramework, который увеличивал счетчик голосования и выглядел примерно как:
using(var db = new DbContext())
{
var vote = db.getVoteById(id);
vote.count++;
db.SaveChanges();
}
Этот код разумеется рушился при конкурентном обновлении. До того, как начать падать, оно проработало примерно год.
А вся беда в том, что в айти отсутствует стремление к специализации. Сама субкультура подталкивает людей к тому, чтобы они били себя пяткой в грудь и говорили, что все знают и умеют, и занимались не своим делом. Вместо того, чтобы честно сказать "я это не знаю, и делать не буду, пока не узнаю, это потребует длительного времени,
идите нах".Но и второе тоже хорошо. ORM, которые явно держат транзакции - встречаются редко. И уж точно в них не полезет разработчик без опыта.
no subject
год проработало, бобла сорвали, а там хоть трава не расти. следующий.
no subject
Просто многие лезут куда не надо своими грязными ручками. Гуевозитель после примеров на бейсике херачит в РСУБД, вообще не представляя что это и какие вопросы оно решает.
По объективным причинам лезут, да -- поскольку спрос всё равно превышает предложэние, но от этого не легче.