Да, именно так всё. Ну, мой второй вариант похож на то, что вы предлагаете, только лучше, по-моему, хранить в мемкэше общий пул сообщений, а для каждого клиента полный список ссылок на те сообщения, в которых он заинтересован. Нормализация типа :)
— хранение истории (плюс работа с ней в админке, но до этого ещё не дошёл)
— передача данных между запросами
— основное приложение :)
C perl'ом совсем не знаком, и судя по тем примерам, что видел, мне проще демона на простом Си написать будет с нуля, чем допиливать готовое решение на перле
VDS не мастерхостовский, KVM — обещано 1 физ. ядро и 1 Гб ОЗУ, завтра сам сервер погоняю на предмет бенчмарков всяких, но разве что с диском проблемы. Индекс для выборки сделан (вернее все возможные сделаны), судя по EXPLAIN работает (только один из всех). Представления использовать не хочется, не люблю логику в БД :( А вот насчёт memory таблиц — спасибо за идею! Как-то в голову не пришло, что можно писать параллельно в две таблицы :) В принципе получается тот же мемкэш, только без стороннего софта и со знакомой логикой :)
Тестировали даже вообще без фронтенда (если иметь в виду под ним php скрипт), шелловским скриптом SQL запросы напрямую к серверу, запускаемым в параллельных шеллах. Без фронтенда держит около 30, потом не успевает за секунду отвечать, то есть ответ ещё не пришёл, а уже надо посылать новый запрос, чем дольше работает и чем больше клиентов, тем сильнее отставание нарастает. Опросы да, периодические, раз в секунду каждый клиент спрашивает у сервера «дай мне новые публичные и мои приватные сообщения начиная с id такого-то, но не более 50». В тесте вероятность того, что появилось новое сообщение чуть больше 50% (один скрипт каждую секунду шлёт INSERT с публичным сообщением, следующую секунду со случайным получателем). Собственно потому и появилась идея хранить где-то в глобальной памяти пул свежих сообщений и списки ссылок на нужные для каждого клиента сообщения, что заносить один раз сообщение в БД, а потом его оттуда 100 раз читать разными запросами явно не рационально, если БД не может (а она явно не может), при инсерте подготавливать кэш ответов заранее.
Куча разных (условия в WHERE разные) запросов на чтение идут раз в секунду, раз же в секунду база изменяется, кэшировать результаты у СУБД не получается.
Если какая-то Катя сможет доказать, что вы имели в виду её, то это будет преследоваться законом, но другим (слышал байку, не знаю правда или нет, но одна судья кому-то после обвинительного приговора (очень мягкого) сказала: «да я сама вижу, что дура и стерва, но по закону он её оскорбил, хотя я его понимаю» :) ). Персональные данные тут не причём.
Думаю, что будет, если серьезно взяться. Неисполненный приговор российского суда закрывает для них возможность вести цивилизованный бизнес в России. Другое дело, что вряд ли они будут разбираться с индексацией, видимостью «только для друзей» и т. п., а будут просто по первому обоснованному (то есть юридически значимому) требованию удалять аккаунты, а без такого требования суд их обяжет ровно на то же, вот за неисполнение этого обязательства или за отказ выполнить правильно оформленное требование могут наказать и сильнее (моральный вред, штраф, и, теоретически, даже уголовная ответственность, но с этим намного сложнее)
1) персональные данные — любая информация, относящаяся к определенному или определяемому на основании такой информации физическому лицу (субъекту персональных данных), в том числе его фамилия, имя, отчество,…
Моя фамилия ко мне относится, а значит является моими персональными данными, то что чисто по фамилии меня найти нельзя ничего не значит, в законе союз «или».
>Э, нет уж! На ФБ данные вводили добровольно?
Вообще:
12) общедоступные персональные данные — персональные данные, доступ неограниченного круга лиц к которым предоставлен с согласия субъекта персональных данных или на которые в соответствии с федеральными законами не распространяется требование соблюдения конфиденциальности.
3. Обязанность предоставить доказательство получения согласия субъекта персональных данных на обработку его персональных данных, а в случае обработки общедоступных персональных данных обязанность доказывания того, что обрабатываемые персональные данные являются общедоступными, возлагается на оператора.
4. В случаях, предусмотренных настоящим Федеральным законом, обработка персональных данных осуществляется только с согласия в письменной форме субъекта персональных данных.
Сомневаюсь, что кто-то давал фейсбуку разрешения в письменной форме :)
Суд если что решает (сам или на основании экспертизы) — есть такое понятие «схожее до смешения», его пишут в таких случаях в исковых заявления о запрете использования, а суд уж смотрит так это или нет, а сначала вообще есть ли у истца право требовать запрета.
Ну, тогда ещё встраиваемые и всё, пожалуй. Хотя, распределенные реплицируемые системы (master-slave или равноправные реплики) сложно однозначно отнести к клиент-серверным, поскольку один и тот же экземпляр СУБД может выступать и в роли сервера, и в роли клиента.
если x не уникальное (ну и вообще нарушений целостности и т. п. не будет), то вторая вставка не сфейлит, а нормально продублирует записи — транзакции тут не спасут.
Подавляющее большинство посетителей обычных сайтов и не догадывается об инфраструктуре сертификатов, УЦ и т. п., если не выдаётся ошибки (грубо говоря, если сертификат подписан доверенным центром — то всё ОК, для пользователя всё прозрачно)
