Какие способы нумерации версий существуют?

Спасибо, появилось немного пищи для размышлений.
В том то и дело, чтобы применить способ которые подходит, необходимо представлять какие способы есть :)

Какие способы нумерации версий существуют?

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

Какой SSD выбрать?

расскажите как вы используете свои винты?..

Как с помощью rewrite в Nginx отдавать вместо test.js результат выполнения test.js.php?

@VBrat
Да, возможно вы скорее всего правы больше чем я. Я лишь предложил путь решения, более точнее мне сложно помочь, т.к. дела с fastcgi + nginx я не имел.

Спасибо за исправление.

Как с помощью rewrite в Nginx отдавать вместо test.js результат выполнения test.js.php?

Или можно что-то в этом роде, если все js'ы у вас через php

fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name.php;

Как поделить большую таблицу личных сообщений?

конечно, как завершим «переезд» сделаю пост

Кеширование данных "правильнее" описывать в модели или контроллере?

спасибо за ссылки. завтра буду изучать :)

Кеширование данных "правильнее" описывать в модели или контроллере?

спасибо, таки в эту сторону походу начинает склоняться большинство.
а какой framework используете?

Кеширование данных "правильнее" описывать в модели или контроллере?

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

Знаете ли вы где можно посмотреть примеры такого подхода в живую. Исходники чего-то или может какой-то статьи?

Спасибо в любом случае.

Как поделить большую таблицу личных сообщений?

классная презентация, спасибо.

Как поделить большую таблицу личных сообщений?

bugman
У этого пользователя было 1133 новых сообщения на момент селекта. Всего больше.
Кол-во запросов count — много :(

Как поделить большую таблицу личных сообщений?

как раз от такого REPAIR TABLE и хотим избавиться. Переход на InnoDB будет скорее всего во время дробления таблицы.
limit используем для пейджинга, count(*) для того чтобы показать счетчик :)

скорее всего вы таки правы про блокировки, надеюсь прорвемся когда будет InnoDB.
status = emum — вы правы.

Как поделить большую таблицу личных сообщений?

bugman
да и join подойдет только в рамках одного шарда, если учитывать развитие на будущие, то join'ов все равно придется отказываться :/
тригер тоже выход если оставаться в рамках только одной базы, а если случится так что данные будут разнесены на разные шарды и разные базы. например какой шард вышел из строя и его данные перенесли в другие базы из бекапа.

Как поделить большую таблицу личных сообщений?

спасибо, сейчас буду смотреть

Как поделить большую таблицу личных сообщений?

в первом случае можно использовать построчные выборки, вместо join'a. тем более если в дальнейшем планировать шардинг, от join'а в любом случае придется избавляться.

select msg_ids from message where owner_id = USER_ID
select * from message_status where id in ( foreach(msg_ids) )

про explain написал в комментарии к вашему ответу.

Как поделить большую таблицу личных сообщений?

Запрос например такой

select * from message where to_id = user_id and status = 'new'
или такой
select count(*) from message where to_id = user_id and status = 'new'

индекс сделан по to_id и status. чем еще может помочь explain в таком случае?
скорость выполнения запроса по разному, в зависимости от нагрузки. от 0.2 секунды до 1-2 секунд, это без ожидания локов. Смотря сколько сообщений у пользователя.

Таблица myisam.

> explain select * from msg where to_id = USER_ID and status='new';

select_type | table    | type | possible_keys   | key             | key_len | ref   | rows | Extra      
------------+----------+------+-----------------+-----------------+---------+-------+------+------------
SIMPLE      | msg      | ref  | idx_toid_status | idx_toid_status | 3       | const |  893 | Using where


> explain select count(*) from msg where to_id = USER_ID and status='new';


select_type | table    | type | possible_keys   | key             | key_len | ref   | rows | Extra      
------------+----------+------+-----------------+-----------------+---------+-------+------+-------------------------
SIMPLE      | msg      | ref  | idx_toid_status | idx_toid_status | 3       | const |  893 | Using where; Using index

> select count(*) from msg where to_id = USER_ID and status='new'; 

count(*) 
---------
    1133

Что-то еще интересует. Спасибо за то что откликнулись.

p.s. давайте жить дружно, все кто отвечал, ответили на поставленный вопрос в том направлении в котором я хотел обсудить вопрос, кому было интересно или необходимо задали дополнительные вопросы.

Как поделить большую таблицу личных сообщений?

bugman
Спасибо, хорошая идея как перепланировать таблицу. Понравилась очень. Пришла следующая идея как реализовать, интересно ваше мнение.

Message
msg_id — ID сообщения
owner_user_id — владелец сообщения
partner_user_id — собеседник
date — дата сообщения
direction — направления сообщения

Message_status
msg_id — ID сообщения
status {new, read, replied} — статус сообщения

Message_body
msg_id — ID сообщения
body — тело сообщения

Message шардиться по owner_user_id.
Message_status и Message_body по msg_id

Имеем у каждого свои письма, при этом общие для всех писем тело письма и статусы. Вот только есть вопрос, оставлять date в Message или перенести в Status. С одной стороны он полезнее в Message можно сделать order с другой стороны это общее для двух пользователей информация которая может жить в Message_status.

P.S. Кстати, записи из таблиц не удаляются ставиться флаг удаления. быстрее т.к. индексы не переписываются

Как поделить большую таблицу личных сообщений?

2-й вариант нравиться больше, только пугает время когда придется увеличить кол-во шард, надо будет предпринемать какое-то действия для перераспределение инфы исходя из нового кол-ва шардов, и тут уже не ясно к чему это может привести :( во всяком случае опыта такого не было, а в теории звучит как восстановление RAID массива при падении винта. Есть идеи как этого можно избежать?

Я, например, из презентации Пинтереста не понял как они умудряются получить этот самый ID, мне очень понравилось идея, что любые структуры пользователя можно переносить между базами внутри шарда ну и между шардами соответственно. Вот только я никак не смог понять как они «добывают» эту самую адресацию :(

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

Как поделить большую таблицу личных сообщений?

Есть запросы:
select * from message where to_id = USER_ID — инбокс
select * from message where from_id = USER_ID — аутбокс
select * from message where (to_id = USER_ID and from_id = SENDER_ID) or (to_id = SENDER_ID and from_id = USER_ID) — получить историю переписки

Поделить по партициям спасет или инбокс или аутбокс. Запросов в инбокс больше, где-то 50%, остальных по 25%

Вы не подумайте, я за партиции, просто при таком кол-ве записей и такими запросами к сожалению это не выход :(

Как поделить большую таблицу личных сообщений?

Тоже пришла такая мысль, побоялся дублирования. С другой стороны «бекап».
Тут встает вопрос изменения флагов — прочитано отвечено, надо будет на двух шардах, плюс редактирование не прочитанного сообщения… В любом случае спасибо за помощь! Можно будет попробовать реализовать в ближайшем будущем.

Подскажите такой вопрос, как на стадии логина когда вводиться email и пароль, определить на каком шарде живет пользователь? Можно делать хеш по мылу, и уже с ним что-то решать. Вот только как тогда миграцию тогда сделать :(