Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
На вход из БД могут заходить два вида дат: (mysql)
- TIMESTAMP "2016-11-13 05:29:38"
- VARCHAR "13.11.16 05:29"
На выходе получаем единый формат "16.11.2016 05:29"
Хранить дату в varchar ? Это модно ))
Гурманов прошу обратить внимание на строку 19. Как там органично не указаны {} в секундах
P.P.S. Проверил. У меня strtotime вообще не распознаёт формат с точками: если написать только дату без времени, то выводит сегодняшнее число; если написать дату со временем, то выводит 1 января 1970.
Когда заметил, что протупил с обрезанием даты в методе, то время редактирования поста уже вышло.
Спасибо за подсказку date_create_from_format(). Пытался ночью найти эту функцию, да был очень сонный ))
Вот новый вариант функции. Можно отдельным постом вешать - знатный изврат вышел. Будет такой костыль, пока не приведу в порядок поле в БД
public static function data_convert($data){
try{
try{
$dt = new DateTime($data);
}catch(\Exception $e){
$dt = DateTime::createFromFormat('d.m.y H:i', $data);
}
return $dt->format('d.m.Y H:i');
}catch(\Exception $e){
return $data;
}
}
Вот сразу видно что ты нихуя не умеешь, потому даже не смог ответить по существу. Высер убера давно уже обосран, ибо там много ламерской чуши, начиная от высера про многопоточность.
Funny article by Uber. The only real issue they found is Write Amplification. That is probably can be an issue for huge sites.
>>Replication
Postgres supports statement-based replication by third party tools like http://www.pgpool.net/ which is de-facto standard.
That is shame not to have such a good functionality built in, but MySQL lacks so many tools so there is even a company named Percona which produces tools to manage mysql
replication and backup.
>>Data Corruption
Wow, they found a bug in Postgres. I am sure MySQL is bug-free
>>Replica MVCC, Postgres Upgrades
Again: statement updates are available to solve this issue.
>>The Buffer Pool
Following sentence is lie: "Postgres allocates some memory for internal caches, but these caches are typically small compared to the total amount of memory on a machine."
From postgres manual on shared_buffers (postgres analogue of mysql buffer pool):
"shared_buffers: If you have a dedicated database server with 1GB or more of RAM, a reasonable starting value for shared_buffers is 25% of the memory in your system"
>>Connection Handling
This is not true, at least for Linux: "Postgres, however, use a process-per-connection design. This is significantly more expensive than a thread-per-connection design for a number of reasons."
Process is not "significantly more expensive" than thread on Linux. But they probably use Windows, I am not sure.
There are a lot of features Postgres has and MySQL/InnoDB does not (smart query optimizer, true constraints, cached views, calculated columns, etc), but they are probably not used by Uber.
В общем случае неверно. Даже если закрыть глаза на то, что процессы влекут оверхед по памяти (надо где-то хранить дескрипторы и прочие метаданные), процессы в отличии от потоков живут в разных адресных пространствах, значит при переключении процессов нужно сбросить все кеши и TLB, например. В железе есть некие оптимизации супротив этого, но железо не резиновое.
Ну и между процессами нужно IPC какое-то, по умолчанию они друг-другу в память гадить не могут, значит любое взаимодействие между ними = оверхед.
> В железе есть некие оптимизации супротив этого
Ну вот как раз, когда 10к что-то делающих процессов, от этих оптимизаций мало пользы. Пока процесс опять попадет на выполнение (да на то же ядро), весь тлб вымоет.
всё говно кроме мочи
постгря не эталон
у нас уже в портфолио прилично нагруженных проектов на ней
вакуум это самый атас, постгря плохо дружит с тем, чтобы очень часто и очень много апдейтить тыщи строк
был такой проект, когда мы пиздили снапшотами состояния flightradar24 и marinetraffic (ну и до кучи прочие системы, куда фантазия заказчика достигала)
по сути, раз в N минут (N около 5 для самолётиков) поллили все объекты из внешней системы, сохраняли все отрезки пути, куда кто сместился (ну и плюс вытаскивали все описания, картинки и т.д.)
за один снапшот около 10к объектов приходило, ну и 10к * k отрезков пути
схему я сделал ещё не зная о адовом подарке от создателей постгреса, в котором любой апдейт строки создает в хвосте таблицы новую копию этой строки, не важно, нужна ли была старая строка кому-то или нет (вместо того, чтобы где-то в отдельных блоках хранить и потом по старому месту после коммита присунуть новое состояние), а таковых объектов было немало, т.к. если объект уже тречился в системе, то ему обновляли last_path_segment_id, ну и для path_segment тоже в целях ускорений (уточка говорит зря зряя) сделали двунаправленный список (next/prev path segment id), ну и понятное дело, когда объект пропадал, мы его тоже архивировали и в итоге тёрли вместе с сегментами
короче, по умолчанию включенный автовакуум положил продовую систему - джобы на добавление новых объектов висели в очереди, очередь росла, хотя это какие то сраные 10к изменений базы в минуту (т.к. операция вакуум блочит таблицу целиком, пока не закончится), что для любой другой субд ну откровенно говоря хуйня
притом, что в ресурсах там не было лимитов, железо топовое
пока игрались с ручными настройками вакуума бд, база росла за сутки на десятки гигов, из которых "живых" строк было ну вот те же самые 10к объектов + сколько то там им сегментов пути (ну допустим x100) - всё потому, что постгрес продолжает писать в хвост таблицы, пока не сделается вакуум
в итоге сейчас оно ночью чистится вилкой и работает стабильно ну уже года полтора
но осадочек от автовакуума остался
да, у постгри создаются новые rows и потом делается gc
так устроен там mvcc. потому аргумент про засирание это ЕДИНСТВЕННЫЙ правдивый аргумент в уберовом высере.
Все остальное там чушь.
Зато в постгре есть охулиард фич которые есть в нормальных субд и которых нет в mysql. Тебе-то не надо перечислять,ты же вкурсе наверняка что в mysql даже констреинтов нет.
самый охуенный оптимизатор в оракле, постгресовскому до него еще пилить и пилить, sad but true
буквально вчера видел тупейший фейл постгреса - построил btree индекс на таблице по колонке baz, которая FK, ну с целью быстро и охуенно считать select count(*) from foo.bar where baz = :1
оракл бы сделал range scan по индексу, count на след шаге и все, кост был бы примерно 2
постгрес какого то хера сделал bitmap scan по индексу (почему битмап, подумал я, там ведь разнообразие этих значений больше тыщи, ну да хуй с тобой, может, это у тебя ренж такой) и... и... полез в материнскую таблицу через nested loop, а уж потом count
причем, select(baz) или select(1) естесно никак ему не помогли, как и аналайзы
с другой стороны за $0 очень годно, каких то фич оракловых нет, есть зато сотни своих
> не видит разницы между процессами и потоками
Потоки проц вообще не видит, для него это просто сохранение и загрузка регистров. А от процессов он видит только таблицу страниц (а на некоторых архитектурах - и её не видит).
Видит. При переключениями между потоками разных процессов адресное пространство меняется, меняется таблица страниц, процессор либо сразу сбрасывает кэш этой таблицы, либо начинает это делать постепенно. При переключении между потоками одного процесса этого не происходит.
при создании нового процесса через fork() (а так же clone() итд)будут использоваться же самые страницы в памяти что и для старого процесса, пока он не начнет в них что-то писать.
Почитай ты уже что-нить про линукс, Лава почитай хотя бы, не позорься
Вот ты дурак. Хватит уже думать, что ты самый умный. Не придумали пока способа удалять из кэша только отличающиеся страницы. Так что при переключении процесса тлб чистится не зависимо от содержимого страниц.
Зачем ты споришь о неизвестных тебе вещах? Я уже понял, что ты не знаешь, что такое виртуальная память. Иди читать. Еще раз слова для поиска: виртуальная память, mmu, tlb.
Я прекрасно знаю как работает mmu, но tlb тут не при чем!
еще раз: у процессора нет понятия "поток" и "процесс": у него есть понятие "task". Понятие "поток" и "процесс" может быть у операционки. У линуксового ядра разницы между этими понятиями практически нет. Пока ты не прочитаешь приведенную мною ссылку, я не буду тебе ничего говорить. Всё.
Я прекрасно знаю, как устроены потоки в линуксе, и что форк реализован через клон. Не надо повторять это, как попугай. То что потоки и процессы одно и то же - это пиздешь. Потоки с разными адресными пространствами одним - это не одно и то же.
Ты сейчас рассказал о том, что кеши могут протухать. В этом никто не сомневался и так, вопрос в том, сбрасывается ли TLB полностью или нет. Сейчас добилдится doxygen для прыщей, и мы всё (надеюсь) узнаем.
ладно, посыпаю голову пеплом: TLB перегрузится если process block другой. Ну с таким же успехом оно перегрузится когда шедулер запустит на этом ядре другое приложение (у тебя же не только постргря на машине) и когда ты в kernel space пойдешь тоже может поменяться. И по-прежнему не доказано что это хоть как-то серьезно влияет на перформанс. TLB полезен чтобы не ебаться с таблицами страниц в рамках одного кванта, а квант это же вечность по компьютерным меркам. У тебя есть какие-то бенчмарки?
за щеку, проверь
Во-первых, ещё вовсе не ясно, что хуже: зафлашить весь TLB разом несколькими инструкциями и потом огрести thrashing, замедляя приложения, или же инвалидировать его точечно, но выполняя сложный обход с кучей инструкций, замедляя context switch.
Во-вторых, необходимость полной инвалидации кешей дико меняется с новыми архитектрурами.
В-третьих, с не выставленным CPU affinity ядро само успешно инвалидирует все кеши путём перекидывания процесса между ядрами, но TLB бывает многоуровневым, поэтому оценить масштаб бедствия очень сложно.
Короче, да, в первом приближении на современных архитектурах вне лабораторных условий разница в производительности не должна быть слишком заметной.
Представим себе что у нас квадратный конь в вакууме, и есть два процесса и два ядра cpu.
Разве шедулер начнет менять их местами просто так, от нечего делать?
Я думаю что нет, он оставит каждый процесс при своем cpu.
Теперь представим что у нас 158 процессов и 2 CPU.
Пусть процесс привязан к ядру 1.
Значит-ли это что никакой процесс не сможет больше выполняться на ядре 1? Если да, то это адский проеб ресурсов.
Если нет (то-есть это просто значит что он всегда будет выполняться только на этом ядре), то как только первый процесс уснет (или просто кончится его время) туда сразу же придет другое приложение и пизда придет TLB.
В двух подходящих форматах поля идут в порядке, противоположном ожидаемому, так что использовать strtotime в лоб не получится.
Кстати, методы класса DateTime можно использовать и «в процедурном стиле»:
P.S. Всё-таки "Y-m-d H:i:s" strtotime проглатывает (распознаёт год, когда он четырёхзначный), но на втором формате глючит.
http://ideone.com/QxTavL
В общем, никогда не используйте strtotime. Лучше сразу date_create_from_format.
Спасибо за подсказку date_create_from_format(). Пытался ночью найти эту функцию, да был очень сонный ))
Вот новый вариант функции. Можно отдельным постом вешать - знатный изврат вышел. Будет такой костыль, пока не приведу в порядок поле в БД
та же постгря в миллиард раз лучше
https://eng.uber.com/mysql-migration/
> не дешевле
И опять ты в лужу перднул. Рано тебе еще в интернете спорить, иди домашку делать.
слив защитан)
Вот тебе более развернутый ответ, где я ппкс
Funny article by Uber. The only real issue they found is Write Amplification. That is probably can be an issue for huge sites.
>>Replication
Postgres supports statement-based replication by third party tools like http://www.pgpool.net/ which is de-facto standard.
That is shame not to have such a good functionality built in, but MySQL lacks so many tools so there is even a company named Percona which produces tools to manage mysql
replication and backup.
>>Data Corruption
Wow, they found a bug in Postgres. I am sure MySQL is bug-free
>>Replica MVCC, Postgres Upgrades
Again: statement updates are available to solve this issue.
>>The Buffer Pool
Following sentence is lie: "Postgres allocates some memory for internal caches, but these caches are typically small compared to the total amount of memory on a machine."
From postgres manual on shared_buffers (postgres analogue of mysql buffer pool):
"shared_buffers: If you have a dedicated database server with 1GB or more of RAM, a reasonable starting value for shared_buffers is 25% of the memory in your system"
>>Connection Handling
This is not true, at least for Linux: "Postgres, however, use a process-per-connection design. This is significantly more expensive than a thread-per-connection design for a number of reasons."
Process is not "significantly more expensive" than thread on Linux. But they probably use Windows, I am not sure.
There are a lot of features Postgres has and MySQL/InnoDB does not (smart query optimizer, true constraints, cached views, calculated columns, etc), but they are probably not used by Uber.
Чтд. С твоими хомпагами действительно разницы нет.
То-есть ты реально не только в субд нихуя нибумбум, но и в английском?
Это похвально. сразу бы так)
http://stackoverflow.com/questions/807506/threads-vs-processes-in-linux
Ну и между процессами нужно IPC какое-то, по умолчанию они друг-другу в память гадить не могут, значит любое взаимодействие между ними = оверхед.
Ну вот как раз, когда 10к что-то делающих процессов, от этих оптимизаций мало пользы. Пока процесс опять попадет на выполнение (да на то же ядро), весь тлб вымоет.
шаред мемори же
постгря не эталон
у нас уже в портфолио прилично нагруженных проектов на ней
вакуум это самый атас, постгря плохо дружит с тем, чтобы очень часто и очень много апдейтить тыщи строк
по сути, раз в N минут (N около 5 для самолётиков) поллили все объекты из внешней системы, сохраняли все отрезки пути, куда кто сместился (ну и плюс вытаскивали все описания, картинки и т.д.)
за один снапшот около 10к объектов приходило, ну и 10к * k отрезков пути
схему я сделал ещё не зная о адовом подарке от создателей постгреса, в котором любой апдейт строки создает в хвосте таблицы новую копию этой строки, не важно, нужна ли была старая строка кому-то или нет (вместо того, чтобы где-то в отдельных блоках хранить и потом по старому месту после коммита присунуть новое состояние), а таковых объектов было немало, т.к. если объект уже тречился в системе, то ему обновляли last_path_segment_id, ну и для path_segment тоже в целях ускорений (уточка говорит зря зряя) сделали двунаправленный список (next/prev path segment id), ну и понятное дело, когда объект пропадал, мы его тоже архивировали и в итоге тёрли вместе с сегментами
короче, по умолчанию включенный автовакуум положил продовую систему - джобы на добавление новых объектов висели в очереди, очередь росла, хотя это какие то сраные 10к изменений базы в минуту (т.к. операция вакуум блочит таблицу целиком, пока не закончится), что для любой другой субд ну откровенно говоря хуйня
притом, что в ресурсах там не было лимитов, железо топовое
пока игрались с ручными настройками вакуума бд, база росла за сутки на десятки гигов, из которых "живых" строк было ну вот те же самые 10к объектов + сколько то там им сегментов пути (ну допустим x100) - всё потому, что постгрес продолжает писать в хвост таблицы, пока не сделается вакуум
в итоге сейчас оно ночью чистится вилкой и работает стабильно ну уже года полтора
но осадочек от автовакуума остался
так устроен там mvcc. потому аргумент про засирание это ЕДИНСТВЕННЫЙ правдивый аргумент в уберовом высере.
Все остальное там чушь.
Зато в постгре есть охулиард фич которые есть в нормальных субд и которых нет в mysql. Тебе-то не надо перечислять,ты же вкурсе наверняка что в mysql даже констреинтов нет.
это query optimizer перделка?;)
лол, хуесто, сразу видно что ты ничего кроме лабы с субд не делал
буквально вчера видел тупейший фейл постгреса - построил btree индекс на таблице по колонке baz, которая FK, ну с целью быстро и охуенно считать select count(*) from foo.bar where baz = :1
оракл бы сделал range scan по индексу, count на след шаге и все, кост был бы примерно 2
постгрес какого то хера сделал bitmap scan по индексу (почему битмап, подумал я, там ведь разнообразие этих значений больше тыщи, ну да хуй с тобой, может, это у тебя ренж такой) и... и... полез в материнскую таблицу через nested loop, а уж потом count
причем, select(baz) или select(1) естесно никак ему не помогли, как и аналайзы
с другой стороны за $0 очень годно, каких то фич оракловых нет, есть зато сотни своих
давно уже innodb по дефолту
да и query "optimizer" в мускулях не всегда зависит от движка
но postgresql geqo конечно дает посасать мускулю очень сильно.
Да и не только он . WITH дает, Window functions дает, вычисляемые поля, тысячи их!
Сравнивать mysql с postgres это как notepad с wordом
Потоки проц вообще не видит, для него это просто сохранение и загрузка регистров. А от процессов он видит только таблицу страниц (а на некоторых архитектурах - и её не видит).
Проц не видит относятся потоки к одному и тому же процессу или нет. Ему похуй.
Почитай ты уже что-нить про линукс, Лава почитай хотя бы, не позорься
еще раз: в ядре линукса _НЕТ_ разницы между потоком и процессом.
Тебе на русский перевести http://stackoverflow.com/questions/807506/threads-vs-processes-in-linux?answertab=votes#tab-top ?
еще раз: у процессора нет понятия "поток" и "процесс": у него есть понятие "task". Понятие "поток" и "процесс" может быть у операционки. У линуксового ядра разницы между этими понятиями практически нет. Пока ты не прочитаешь приведенную мною ссылку, я не буду тебе ничего говорить. Всё.
Борманд, ну ты же умный парень, объясни уже хуесте что НЕТ разницы по перформансу между потоком и процессом на линуксе (на винде -- есть)
1) страницы кода у тебя ОДИНАКОВЫЕ, правда?
2) Стеки у тебя ВСЕГДА разные что для потока в том же процессе, что в другом
3) В потоке может быть своя куча, а в треде свой тред локал
4) "static" может быть свой у процесса но создается только при новой записи (copy on write).
за щеку, проверь
Во-первых, ещё вовсе не ясно, что хуже: зафлашить весь TLB разом несколькими инструкциями и потом огрести thrashing, замедляя приложения, или же инвалидировать его точечно, но выполняя сложный обход с кучей инструкций, замедляя context switch.
Во-вторых, необходимость полной инвалидации кешей дико меняется с новыми архитектрурами.
В-третьих, с не выставленным CPU affinity ядро само успешно инвалидирует все кеши путём перекидывания процесса между ядрами, но TLB бывает многоуровневым, поэтому оценить масштаб бедствия очень сложно.
Короче, да, в первом приближении на современных архитектурах вне лабораторных условий разница в производительности не должна быть слишком заметной.
Представим себе что у нас квадратный конь в вакууме, и есть два процесса и два ядра cpu.
Разве шедулер начнет менять их местами просто так, от нечего делать?
Я думаю что нет, он оставит каждый процесс при своем cpu.
Теперь представим что у нас 158 процессов и 2 CPU.
Пусть процесс привязан к ядру 1.
Значит-ли это что никакой процесс не сможет больше выполняться на ядре 1? Если да, то это адский проеб ресурсов.
Если нет (то-есть это просто значит что он всегда будет выполняться только на этом ядре), то как только первый процесс уснет (или просто кончится его время) туда сразу же придет другое приложение и пизда придет TLB.
Вопрос: как ту поможет affinity?
В общем собака порыта в CLONE_VM.
Позиксовые понятия "процесс" (fork()) и "поток" (pthread_create()) один хуй мапятся в clone()
Просто один с CLONE_VM (и создает новый процесс блок -> флашит TLB) а другой без.
Но на перформанс все равно почти не влияет
context switch почти не влияет, прошу заметить. (Хотя если навыделять много страничек, то всё будет плохо всё равно, что-то мне говорит)
За IPC всё равно придётся в ядро лезть, если не заморачиваться с shared memory. А это плохо.