- 1
Сейчас подниму на сервер автоплюсатор новых постов, чтобы всякие дохуя умные их не топили-
C# / Говнокод #22776
−40
Если он, конечно, работает
Пока +47, завтра нарегаю еще стопицот учетокЗапостил:
cykablyad,
10 Апреля 2017
Follow us!
P.S. доказывать что-то фейк-учетке даже без граватара... фи
Теперь у тебя есть пруфы. Поздравляю.
Кстати, пароль - от учётки carme.
Теперь этот говнокод подберут более тупые 3_15дары и начнут флудить и троллить поболе тебя
www.fayloobmennik.net/6942941
Ты всё время кичишься длиной своего приватного ключа. Я так и не понял, как он тебе помогает/мог бы помогать на ГК.
Никак, я просто выебываюсь
Я даже на гитхабе issue создал, а туда никто не пишет
Собственно, предсказуемо. Плавали, знаем. Если ты не готов смириться, что всём насрать, пока всё не готово (и даже после того, как всё готово), то лучше и не начинать.
Доведём Вас до слёз. Потому, что для нас это просто сайт, а не любимое творение.
На другом ресурсе будет точно то же самое - вспомните ещё мои слова.
Оффтопик по СУБД.
Есть табличка, в которую писатели накидывают новые записи. Есть читатели, которые хотят видеть новые записи и делают запрос в духе id > last_known_id.
Есть ли какой-то более адекватный способ, чем тотальная сериализация всех писателей об одну лочку?
их можно сто штук набрать же
откуда он знает что 4 уже записали, если транзакиця 4 еще не закоммичена?
Поэтому одна транзакция возьмёт себе 4, а вторая - 5. И обе из них пойдут долелывать какие-то ещё вставки/обновления. И в каком порядке они закоммитятся - никто не знает.
ну так ты субд на хуйю провернул, и конечно всё не работает.
делай нормальную транзацию
1) взял
2) увеличил
3) записал
ничем не отличается от
> тотальная сериализация всех писателей об одну лочку
на уровне бека
Ты или юзаешь транзакции или нет
Но вообще это задача для queue а не субд
По моему только в говносраном mysql пыхоинвалиды привыкли делать select max(id)+1 перед тем, как сделать insert, ну или делать говнотаблицу shit.sequences (tablename, nextvalue). Это всё от скудоумия.
В оракле, например, cache у последовательности по умолчанию 20. Это значит, что сервер в принципе держит наготове следующие 20 значений в оперативной области (а сиквенс уже их как бы выдал). Кеш протухает, неиспользованные значения никогда не заинсертятся. Вот и бывают таблицы, где айди вообще выглядят как 21, 41, 61 ... И ничей брат не помер от этого.
Как и не должен помереть от того, что строка с id = 5 появится на долю времени перед строкой с id = 4, а строки с id = 3 вообще не будет, т.к. та транзакция откатилась.
Че с этим делать, не забиваясь в один поток, я предложил ниже.
> Но вообще это задача для queue а не субд
именно
Вообще подобные лочки на беке, если они с малой кровью возможны на беке (к примеру, мутекс в HA-кластере это тоже не хуй собачий) надо делать на беке, т.к. даже самый быстрый субд движок - это ~ 1/1000 скорости бека в подобных операциях
Слон в посудной лавке.
Голосованием, как в raft'е.
Ну так в итоге голосования ты что получишь? Один процесс будет мастером, т.е. держать ЛОК, пока у него большинство голосов.
Как я понял задачу, у тебя есть "читатели", которые должны как бы из очереди забрать сведения из таблицы для обработки.
Если эту задачу уж прямо так хочется решать при помощи средств СУБД, то я бы посоветовал следующий способ (с вариациями):
1) параллельно с инсертом в основную таблицу (например, foo) инсертить в соседнюю foo$unprocessed (id int8 primary key references foo.id on delete cascade on update cascade). Дополнительно foo$unprocessed может содержать доп колонки, а-ля сведения о читателе, который "забрал" себе запись на обслуживание, или таймстамп записи foo, если он более надежный, чем айди из сиквенса, но её задача быть максимально шустрой.
Читатели работают прежде всего с таблицей foo$unprocessed, делая в ней select ... for update, сортировку, критерии селекта выберешь сам - например, не более 100 записей. Получив массив айдишников, которые теперь принадлежат конкретному читателю, он может обработать полноценные записи, прочитав их из foo. По окончанию обработки читатель удаляет из foo$unprocessed к хуям залоченные в селекте строки, коммитит.
Т.о. таблица foo$unprocessed будет очень небольшая по размеру, предоставлять очень быстрый DML и, главное, select for update будет делать row lock, а не лок на всю таблицу/систему, при этом не позволять проебываться записям.
В постгресе, например, есть вообще охуенная конструкция select for update skip locked, которая тебе даст практически то, что нужно для нескольких читателей.
2) если не хочется создавать таблицу рядом, можно сделать то же колонками прямо в foo. Этот вариант мне нравится меньше, у него только минусы по сравнению с первым вариантом. Могу рассказать подробнее.
3) к хуям эти dbms-based трюки, делаешь шину между пейсателями и читателями, которая, конечно, и в базу что-то персистит, но это не влияет на её основную задачу.
На работе не до ГК, сорри :(
Не, мне не очередь нужна. Всё прозаичнее - тупо лента с комментами. Поэтому сохранять unprocessed на каждого читателя (я не знаю, сколько их вообще) будет немного невыгодно.
Так что, наверное, проще сериализовать писателей об лочку или вообще заменить sequence на таблицу с полем-счётчиком и select for update + update (та же лочка, просто неявная). И монотонность будет, и читателям не повредит...
и каменты не банковские транзакции - не так и критично не проебать камент, созданный за миллисекунду до твоего запроса контента, не надо героически решать проблему, которую можно решить негероически (показывать не только все непрочитанные каменты, но и каменты за последние N секунд/минут, относительно last_read_time)
Но, если пирфоманс вставок не так уж критичен, то проще монотонность айдишников поддержать, чем поставить всё на атомные часы ntpd и монотонность времени.
А вот это, походу, само то, если у меня до вебсокетов руки дойдут...
Жаль только, что у семи нянек дитя без глазу
В принципе, самый нужный функционал уже готов - бесконечная лента да фильтр от гостя-спамера.
Страйкер - хуесос, сам ничего не делает и другим не дает. Не удивлюсь, если он и есть шизик-минусатор.
Он дал Вам возможность перевоспитывать уебанцев, а не просто банить их.
В данный момент я дрочу свой кривой хуй. Подставь щёчку, скоро потечёт.
Нам не стоит общаться слишком много, а то я привыкну к Вам и потом мне будет тяжело с Вами расставаться.
Вы появились довольно неожиданно; где гарантии, что Вы снова не пропадёте?
Дочь Царя?