- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
/**
* Конвертация формата времени в удобочитаемый вид
* @param mixed $data
* @param mixed $year
* @param mixed $time
* @param mixed $second
*/
public static function data_convert($data, $year, $time, $second){
$res = "";
$part = explode(" " , $data);
$ymd = explode ("-", $part[0]);
if(count($ymd)==1){
$ymd = explode (".", $part[0]);
$ymd[2]="20".$ymd[2];
$ymd = array_reverse($ymd);
}
$hms = explode (":", $part[1]);
if ($year == 1) {$res .= $ymd[2]; $res .= '.'.$ymd[1]; $res .= '.'.$ymd[0];}
if ($time == 1) {$res .= ' '.$hms[0]; $res .= ':'.$hms[1]; if ($second == 1) $res .= ':'.$hms[2];}
return $res;
}
Follow us!
В двух подходящих форматах поля идут в порядке, противоположном ожидаемому, так что использовать 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. А это плохо.