Поиск решения для быстрого создания интерфейсов СУБД

Дело, мы сделали так же. Дошли до дизайнера интерфейсов.
Easy easy, real talk :)

По следам highloadcup: php vs node.js vs go, swoole vs workerman, splfixedarray vs array и многое другое

Спасибо за статью, интересная тема оказалось.
Для себя понял, что видимо индексированные массивы всетаки не до конца оптимизировали в 7ке по сравнению с fixed.

По следам highloadcup: php vs node.js vs go, swoole vs workerman, splfixedarray vs array и многое другое

Что-нибудь типа:

$visits[$row['id']] = implode(';', array_values($row));

не тестировали?

По следам highloadcup: php vs node.js vs go, swoole vs workerman, splfixedarray vs array и многое другое

Внутри тоже можно использовать fixed.
Теперь понял, вы убрали оверхэд на создание мелкого массива свойств вовсе.

По следам highloadcup: php vs node.js vs go, swoole vs workerman, splfixedarray vs array и многое другое

Надеюсь это было не на PHP 5 ???

По следам highloadcup: php vs node.js vs go, swoole vs workerman, splfixedarray vs array и многое другое

Решил использовать разбиение трёхмерного массива совместно с SplFixedArray и потребление памяти упало ещё в 3 раза составив 704 МБ

Не понял почему вы не стали хранить данные в формате типа:

$visits[$row['id']] = [
            $row['user'],
            $row['location'],
            $row['visited_at'],
            $row['mark'],
        ];

заняло бы еще меньше на PHP 7 точно

Чек-лист по выживанию сайта

Ну наконец-то появился конструктив.

JOIN на шарде — вполне годная тема, особенно если архитектура изначально предрасположена к шардированию. Это не отменяет того, что возможно придется сделать довыборку данных из другого источника и в этом нет ничего страшного. Транзакции нужно использовать для финансовых операций с этим никто не будет спорить.

Есть другая крайность с которой мне приходится часто сталкиваться — 1 сервер БД который не в состоянии переварить все данные и запросы, блокировки и прочее. Когда приложение написано с огромным кол-вом объединений. Чтобы растащить такую базу нужно очень сильно поднапрячься. Именно поэтому в вебе join больше зло. Потому как даже просто вынос конкретной таблицы на отдельный сервер представляет сложную задачу.

Чек-лист по выживанию сайта

Видимо мы разговариваем на разных языках…

Статья «Чек-лист по выживанию сайта».

Я про join и шардинг (не всегда данные влазят в одну базу и обилие join серьезно усложняет шардирование), а вы мне про справочники и транзакции.

Почему вы решили что я не использую транзакции, опять фантазия?
Не вижу смысла продолжать обсуждение.

Чек-лист по выживанию сайта

Про справочники — это ваши фантазии, как и про полный объем данных по связям без фильтрации.

На эту и смежные темы написаны сотни статей, подготовлены презентации для десятков конференций Highload и прочих

Если лень гуглить:

http://www.myshared.ru/slide/9793/ (слайд 38)
http://highload.guide/blog/sharding-patterns-and-antipatterns.html (к тезису про справочники, и вашему предположению, что все нужные данные на одном шарде)

Чек-лист по выживанию сайта

Интересно, шардинг тоже антипаттерн?

Живем и работаем не в столицах: рынок разработки программного обеспечения в Нижнем Новгороде

Интересных и крупных проектов достаточно, только управляются они обычно из Москвы или заграницы.
Нижегородским компаниям, работающим на внутренний рынок очень тяжело бороться за кандидатов по условиям.

Простая система демонов для Yii2

Скорее решение не «пока нет большой нагрузки», а пока нет сотен тысяч заданий.

Простая система демонов для Yii2

В том варианте, что я предложил: второй воркер, если возьмет ту же задачу, что и первый — не сможет повесить на нее лок, соответственно возьмет следующую по списку

Простая система демонов для Yii2

Очереди в бд — не лучшее решение, но может пригодиться упрощенный псевдокод (применим к MySQL):

// лучше иметь отдельный коннект для очереди
$db->query('SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE');
$db->beginTransaction();

// время, когда считаем lock устаревшим
$locktimeout = '2001-01-01 00:00:00';

try{
 $row = $db->getRow('SELECT * from `queue` WHERE `lock` IS NULL OR `lock` < "'.$locktimeout.'" LIMIT 1');
 $db->update('queue' , ['lock' => date('Y-m-d H:i:s')], 'where `id`='.$row['id']);
 $db->commit();
}catch (Exception $e){
    $db->rollBack();
    // deadlock, try restart transaction, как ожидаемое поведение MySQL
    if($e->getCode() = 1213){
        // принимаем меры
    }
}

Простая система демонов для Yii2

В случае очереди на БД, если 2 инстанса одной...

Зависит от уровня изоляции, если поставить serialized и в транзакции ставить метку в строку, то один запрос отвалится с retry transaction

PHP-Дайджест № 89 – интересные новости, материалы и инструменты (17 – 31 июля 2016)

18.07.2016 Вышел релиз DVelum 1.0.0 Что нового в DVelum 1.x

Многопоточные вычисления в PHP: pthreads

Промахнулся со статическим связыванием, проблема со статическими свойствами.

Многопоточные вычисления в PHP: pthreads

Все бы хорошо, если не большое количчество нюансов, ограничей и отличия работы PHP c pthreads от PHP как такового.
Нельзя быть уверенным, что стандартная языковая конструкция будет работать корректно.
Пример: https://github.com/krakjoe/pthreads/issues/52
И многое другое, типа позднего статического связываня и наследования… Достаточно взглянуть https://github.com/krakjoe/pthreads/issues

Как эксперимент, очень интересная библиотека. В продакшен?… врядли.

Badoo перешли на PHP7 и сэкономили $1M

На вкус и цвет, дело не в этом. Стандартная языковая конструкция не работает. По манулалу ожидается одинаковое поведение по факту нет.

Badoo перешли на PHP7 и сэкономили $1M

Например, если ожидается не 0. По вашему есть разница?

 if(!empty($interval->d)){
  ...
 }
 // и
 if($interval->d >0){
  ...
 }