excalibur

Ещё же есть chromebook pixel, минус только в малом объёме SSD, всего 32 гига. Ну и цена немаленькая.

Я бы обратил внимание, при таких требованиях, на Lenovo Thinkpad t серии. Есть 15-дюймовые, бывают с SSD.

По случайному стечению обстоятельств, сегодня должен получить 15.6" HP ProBook 4545s, AMD A4 4300M. Не знаю какой на нем стоит дистрибутив, но интереса ради, готов поставить на него Debian и дать на несколько дней рута по ssh и нажимать кнопку питания по Вашему требованию :) Ноут беру для знакомых, так что в любом случае придется заливать на него W7, Вы безболезненно сможете произвести на нем любые тесты.

вот я недавно искал habrahabr.ru/qa/40731/. Не совсем ваши требования, но возможно поможет.

DELL Inspiron 5523 посмотрите. Кстати есть версии с предустановленным Linux

Из этого, что-нибудь смотрели?

Чуть выше Anonym первоначально дал неправильный совет, но в комментариях сам же и указал в чем ошибка. sledopit предлагает правильный вариант, но для этого требуются права на сервер допускающие установку дополнительных модулей. Есть еще такой официальный модуль как suexec. Но если разговор про обычный шаред, то там такая задача в принципе не решаема (разве только если указанные модули уже там установлены).

Но лично я на своих серверах предпочитаю связку nginx+php-fpm+chroot. Для каждого сайта рабочие процессы запускаются с правами владельца сайта, допустим u1:u1. На корневой директории сайта стоит 0710 и u1:nginx, на папке log 0770/u1:nginx. На всех остальных файлах стоят права 0640/u1:u1, на папках 0711/u1:u1. Если файл публичный, то он должен относиться к группе nginx. Ни какой php одного сайта ни чего не может прочесть в файлах другого.

Добавьте www-data в группы user1, user2 и user3.
Владельцами каталогов сделайте user1, user2 и user3 соответственно.
Выставьте права 770.

Из таблиц не надо тянуть для всей стены, слишком тяжело.
На счет «кэширования»? А в чем проблема закэшировать ответ на мой запрос? Тот же memcashed отлично закэширует результаты запросы

Select  * from wall_1234 where owner_id=Owner_id_from_request Limit 0, 20

Ладно, давайте я объясню механизм подробнее. В поле «wall_record_content» вся фишка. Оно нам крайне необходимо и именно оно позволяет нам очень легко выводить данные. Но для этого нам придется заплатить тем, что вводить их будет немного сложнее. Но это не страшно, в соц сети намного чаще читают чем пишут.

Начинаем.
Пользователь создает пост на стене друга.

Готовим запрос на сервер. Вначале кипятим воду включаем личные данные пользователя как автора(имя и id в приложении) и id друга для поля id_owner_user в запрос. Отлично, мы молодцы, но это еще не все.

Дальше пользователь вводит описание. Ничего себе. Тоже вставляем эти данные в параметр description нашего запроса. Идем дальше.
Пользователь прикрепляет фото и видео. Чтобы можно было просматривать фото нам необходим адрес маленькой картинки(в дальнейшем буду называть его «превьюшкой» )и адрес страницы, где мы будем просматривать фото в полном размере. Допустим у нас есть несколько способ прикрепления фото: драг-эн-дропом, если фото уже было добавлено на сервер, или сразу с локального компьютера(или телефона)

Если фото было ранее загружено на сервер (то есть эти данные уже записаны в БД), то просто с помощью ajax запроса получаем эти данные из БД.(Возможно и не потребуется, если на страницк у нас уже есть необходимые данные для фото). Полученные данные вставляем в параметр массив Post_images.

Если нет, то ПЕРВЫМ ДЕЛОМ ЗАГРУЖАЕМ ФОТО НА СЕРВЕР с помощью ajax запроса(с помощью него будет проще) и вносим данные о фото в таблицу images. Когда это будет сделано, возвращаем данные ajax запросом. Включаем их в параметр Post_images. Неплохо.

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

Аналогично с видео и аудио. Супер!

Теперь у нас есть полностью сформированные Post запрос с параметрами author_user_id, author_user_name, owner_id, post_description, Post_images, Post_videos. Отправляем на сервер. И не забываем про CSRF-защиту. Мы любим своих пользователей и заботимся о них.

На сервере принимаем данные запрос, обрабатываем его и записываем в БД как я писал в первом посте.
Пример json-a, которые попадет в БД.

content: {
description: Срочно оцени эти супер-крутые фотки! ,
Mysuper_Puper_Images: [{
Photo_link1{
preview:"images.site.com/dsfgdfgsdg.jpg"
link:"www.site.com/viewphoto/345345345345"
},
Photo_link2{
preview:"images.site.com/dsfgdfgsdg.jpg"
link:"www.site.com/viewphoto/345345345345"
}

}],
Mysuper_Puper_Video_links[{
videolink1{}, videolink2{}
}]
и т.д,
}

Вот и все, теперь у нас в базе лежит пост пользователя.

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

Select  * from wall_1234 where owner_id=Owner_Павел НедуровID Limit 0, 20

Наш скрипт получает из базы( или memcashed) результат выполнения этого запроса. Обрабатываем эти данные и выводим их в нашем шаблоне, не забывая все экранировать для предотвращения xss атак. Мы любим пользователей!

В итоге на странице будет выведено:
1)текст записи
2)маленькие картинки, по клику на превьюшку переходим на страницу, где можно просмотреть большую версию.
3)маленькие картинки с кадром из видео, по клику переходим на страницу, где можно просмотреть видео(хм, где-то я уже это слышал)

Пост друга Павлу понравился! Но вот незадача, симпатичные девчонки сегодня ничего не написали. Не горюй, бро, твое время еще придет. А на этом наша программа подходит к концу. В следующей передаче раз мы будем делать новостную ленту. Оставайтесь на связи.

В итоге благодаря моему способу очень легко и быстро выводить записи, ведь все данные мы получаем одним запросом. И легко кэшировать. И индексы тоже можно использовать. Картинки хранятся в таблице images, видео — в videos. Все можно легко просмотреть. Но с реализацией ввода поста придется немного попотеть, но результат того стоит.

P. S. Не принимайте ничего на свой счет, это у меня просто такой стиль.

Я бы сделал так:(читать до конца)
1)создал бы таблицу wall с полями id, author_user_id, author_user_name, owner_user_id, wall_content, где
-id идентификатор записи в таблице-
— author_user_id — идентификатор пользователя создавшего пост
-author_user_name его имя, внесем сюда же, чтобы не делать лишний запрос к таблицам пользователей
-owner_user_id — идентификатор владелец стены
-wall_record_content — контент записи. представляет собой json с полями title, description,images, видео, опросы и что у ваc там есть. пример

content: {
title: SuperProPost,
Mysuper_Puper_Images: [{
Photo_link1, Photo_link1

}],
Mysuper_Puper_Video_links[{
videolink1, videolink2....
}]
и т.д,
}

Структура на самом деле будет немного посложней, но я думаю вы справитесь.
И потом уже в самом скрипте обрабатывать этот json и формировать шаблон. При записи и изменении скриптом формировать этот json и записывать его в БД,

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

Select  * from wall_1234(лучше использовать шардинг чтобы не было по 20 млн записей в одной таблице) where owner_id=Owner_id_from request Limit 0, 20 (к примеру)

На каждые 50 пользователей выделять отдельную таблицу wall_groupId. Таким образом все данные для стены будут получены, внимание, в ОДИН запрос из таблицы на 100-300 тысяч записей, за что БД скажет нам спасибо
Я надеюсь мысль ясна, подкорректируйте под свои нужды.

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

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

Значит минимальное количество запросов получается равным количеству_типов_данных. Для этого нужно выполнить по отдельности запросы которые у меня в UNION, но тогда вручную в коде сортировать эту кашу по датам и группировать по wall_id. Это плохой путь.

Предлагаю такой вариант:

SELECT
	w.id,
	w.description,
	COUNT(i.id) i_cnt,
	COUNT(bp.id) bp_cnt
FROM wall w

INNER JOIN wall_element we_i
        ON we_i.wall_id = w.id
INNER JOIN image i
        ON i.id = we_i.element_id

INNER JOIN wall_element we_bp
        ON we_bp.wall_id = w.id
INNER JOIN blog_post bp
        ON bp.id = we_bp.element_id

ORDER BY w.timestamp

GROUP BY w.id, w.description

Мы получаем список записей, и количество связанных с каждой записью единиц контента. Дальше разделяем ответственность в коде следущим образом:
1. основной код выполняет этот запрос, и бежит по результатам. Смотрит, что есть в конкретной записи. Например видит что картинка, и товар из магазина
2. основной код вызывает соответствующие рендереры, передавая им идентификатор записи wall_id.
3. рендерер сам (своим запросом) достает уже те данные, которые ему нужны оттуда, откуда хочет, в ту модель, которая ему нравится. Это полностью развязывает рендереры друг от друга и от вызывающего кода.

Итого имеем запросов: количество_записей_на_стене * среднее_количество_единиц_контента + 1. Думаю у вас в среднем 1 запись на стене будет иметь ссылку на 1 единицу контента (например пяток фоток, которые рендерер картинок сможет вытащить одним запросом).

Имеем в среднем запросом количество_записей_на_стене + 1. Вполне приемлимо.

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

activity stream не очень важен, разве что он будет хранить дискретные записи, например, создание одной фотографии/заметки, просто для лога. Как вариант, в нем можно хранить wall_message_id, который будет указывать на сгруппированную запись, в которой это действие будет отображаться. Тогда немного облегчается процесс, о котором я писал выше, так как, например, удаляя какую-то фотографию, мы можете найти обратную запись (создание) в таблице activity stream, оттуда выбрать wall_message, из которого уже удалить ту самую фотографию из перечисленной группы.

События, что сказать.
В транспорте, на получении json что-то в стиле:

app.trigger('load'+data.component,data)

В компонентах на это событие:

app.on('loadNews',function(data){/*парсим шаблон*/})

Можно подгружать нужные компоненты, вроде такой схемы:

var callback=function() {
    known_components[component_id](data);
}
if (!known_components[component_id]) {
    load_component_js_from_server(component_id, callback)
} else {
    callback();
}

Можно получить пример json, чтобы лучше понять ситуацию?

есть разного рода javascript шаблонизаторы, думаю вам стоит смотреть в эту сторону. К примеру, handlebarsjs.com/

<form name="myForm">
<textarea name="description[1]"></textarea>
<textarea name="description[2]"></textarea>
<textarea name="description[3]"></textarea>
<textarea name="description[4]"></textarea>
<textarea name="new[]"></textarea>
</form>

Тем что из базы — указать существующие ID в качестве индекса, а новые — с отдельными именами.

Измените запрос так, чтобы он всегда работал со списком id (даже в случае одного). Тогда свободного сможете грузить хоть по одиночке, хоть все вместе.

Далее, можно сделать так, как описывал @igorvar здесь. А именно, доставать параметры статей из кеша, а те статьи, которые в кеше не лежат, грузить из базы данных описанным выше запросом.

Хотя, если всё, что делает Ваш сайт — это выводит статьи (а значит, их максимум 50 на странице), то можно грузить по одной и класть в кеш. Т.е. делать именно так, как описал @igorvar, без изменения запросов.

Кстати, запросы на получения данных по одному id очень хорошо кешируются базой данных. Поэтому если грузить статьи одиночными запросами и выделить базе данных столько оперативки, чтобы ей хватало для эффективного кеширования (зависит от количества данных в Вашей базе данных и количества реально используемых данных в определённый момент времени), то база данных сама будет неплохо кешировать результаты запросов.

В общем, если Вы дадите чуть больше информации, то может оказаться, что у Вас итак всё хорошо.

А кто инициатор взаимодействия? Админка? или сторонний сервис?

Если админка, то зачем вам REST? Может вам больше подойдет SOAP/XMLRPC архитектура?
приложение переводчик — это SOAP сервер
ваша админка — SOAP-клиент

Ограничить запуск того или иного функционала можно банально авторизацией.