@FanatPHP: вот если Вы перестанете психовать как маленькая девочка и внимательно прочитаете вопрос, то автор не собирается все комментарии хранить в json. Он говорит про последние 3 комментария и 10 фотографий. Где Вы, внимательно прочитав вопрос, нашли документы с сотней полей? Мб я действительно невнимателен, но хоть убейте, не могу найти.
@legolas4444: не парьтесь. На чистом sql (а именно это предлагает ФанатПХП) без костылей это не сделать. Будет работать при таком алгоритме:
- запрашивает список постов;
- для каждого поста запрашиваем комментарии с лимитом.
Будет работать более-менее быстро, если правильно расставить индексы + все это можно кешировать.
Описанный Вами подход - денормализация. Только нужно быть с ней осторожным. Не стоит обновлять json после написания каждого комментария, так может получиться казус с рассинхроном. Лучше всего обновлять json'ы асинхронно раз в час, к примеру (или чаще, если нужно). Плюс я бы рассмотрел вариант выноса всего этого добра в отдельную таблицу, так как если Вам надо выводить 20 последних постов, то не стоит считать все это для всех постов, а только для тех, которые сейчас выводятся.
@FanatPHP: Я прочитал, не переживайте. Вы написали, что это чушь на вполне справедливые уточнения в ответе выше. Я Вам и ответил что это не чушь. И накатите коньяка, что ли, нервы успокаивает :)
@FanatPHP Зря Вы так яростно пытаетесь доказать, что это чушь даже не попытавшись разобраться в вопросе. Я понимаю, что Вы могли ничего кроме мускуля и не видеть, но стоит расширять кругозор. Вполне нормальный подход при условиях, описанных @fornit1917 К примеру, посмотрите на PostgreSQL, который в плане адекватности реализации многих вещей ушел далеко вперед от мускуля.
@zydins: По опыту своего бакалавриата - требовать с Вас научной новизны никто не будет. Но правда и нейросеть совсем тривиально. Реализуйте сеть Кохонена. К примеру восстанавливайте текстуры. Вполне пойдет, да еще и на магистерскую можно будет развить.
@komandakycto: Нет, не будет. Так как если Вам понадобится изменить 100 на что-то другое, то Вам надо будет найти все эти места и исправить. А с "толстыми" моделями такой проблемы нет - поменяли в одном методе и забыли. Ну и как выше написали секретарша не должна разбираться с тем что ей дал босс, так как если Вы решите поменять босса, то придется менять и секретаршу. Она должна просто передать указания куда нужно. Очень хорошая аналогия, мне понравилась :) Хотя я лучше пойду поиграю в Доту, ведь я все еще студент (при том, что старше Вас на неделю с лишним) :)
@KoMPoTuK ну в целом Вы имеете право на свое мнение, но мое мнение - java ничуть не уступает C++ в большинстве задач, а в некоторых даже предпочтительней по скорости и качеству разработки. И сервер для онлайн игры одна из таких задач. В любом случае там кроме изучения явы рассказывают про основополагающие моменты при разработке сервера. А уже их Вы можете переложить на любой язык
@KoMPoTuK ну про паттерны я имел ввиду книгу GoF, так как ее знание поможет Вам написать более гибкий и адекватный код. В принципе не обязательно, но очень желательно.
Про Ваш подход - он хорош с пхп, так как там все очень упрощенно. Тут Вам либо придется заниматься упрощением каких-то деталей, чтобы не вдаваться в их реализацию, либо упростить всю задачу в целом. Я бы рекомендовал начать с простого, но решать Вам.
По поводу ссылок: https://tech-mail.ru/video/learn пункт Java, там есть видеозаписи очень толковые для начинающих. Идет изучение основ ява на примере разработки сервера для игры. Минус - домашние задания не доступны, но теорию послушать можно. https://www.udacity.com/course/cs255 - тоже хороший курс по разработки игры для начинающих.
Ну и дальше статьи по темам, которые я перечислил ранее.
@IgorMann Не стоит путать человека без понимания того, что Вы пишите. Websocket это браузерная поддержка сокетов, практически никаких ограничений на протокол передачи данных он не налагает. Подходит, только если игра браузерная. 3 - в базе всегда есть что хранить. К примеру, логин + пароль в хешированном виде для авторизации, рейтинг, опыт пользователя и т. п. Без базы можно обойтись только в самом простейшем случае. 5 - я понимаю, что Вы хотели написать, но человек хочет учится и этой фразой Вы его совершенно запутали. Кеширование бывает в БД (и то не во всех) и заключается в складировании результатов запросов в ОЗУ в те же самые структуры данных (хеш-таблицы, к примеру). Очень сильно помогает в ряде случаев, но большинство вариантов не покрывает и приходится писать кастомное кеширование, которое опять же работает с ОЗУ, но использует более сложную логику кеширования\инвалидации данных
Зачем вы деморализуете человека? Совершенный код однозначно надо прочитать и лучше не раз. Но не стоит даже трогать эту книгу, если вы ещё не умеете программировать - большую часть не поймете, а то что поймёте забудете к тому моменту как научитесь программировать.
А какой вариант предлагаете Вы? Можно заменить куки на локалсторендж, но если у пользователя такое стремление к чистке всего и вся и неумение пользоваться режимом анонимности в браузерах, то не спасет ) Я бы сделал вообще по-другому - при регистрации только бы показывал один раз и в базе контролировал бы показан\не показан. Но я не знаю специфику задачи автора вопроса.
Проблем никаких вроде нет. Транзакция открывается только при первом обращении к БД. Соответственно, если Вы не делаете в запросе обращений к БД, то и оверхеда никакого не будет. А в других случая в принципе и не стоит делать запросы к базе без транзакции. Случаи необходимости безтранзакционной обработки очень редки.
делаем на gevent сервер приложений, один из гринлетов которого слушает новые задачи из gearman. При поступлении задачи создаем гринлет с обработчиком поступившей задачи. И так до бесконечности. Если в качестве задачи пришло изменение задачи - ищем нужный гринлет и говорим что изменилось (к примеру задача завершилась). Веб сервер фактически при нажатии кнопки помещает нужную задачу в gearman. Вроде и все. Это конечно элементарное приближение, но в целом суть должна быть понятна
Да и вообще идея "много-много" потоков - плохая. Если нужно много-много потоков, то посмотрите в сторону gevent либы. Позволит Вам держать большое количество потоков (хотя там это не совсем потоки). "Как между ними задачи перекидывать" - если вы про потоки, то gevent реализует большое количество структура. В частности есть Queue.
@foxmuldercp написав свой язык программирования (даже игрушечный) можно очень хорошо освоиться в языке на котором это будет делаться + освоить сопутствующие технологии. Я в свое время писал многопоточный веб-сервер. На подакшены он попал только в моем проектике, но опыта от его написания я получил гору
@saintbyte т.е. Вы написали бота, который спарсил весь вконтакт и определил, что вся база ВК весит 1Тб? Мне кажется, что реальные цифры значительно больше, так как кроме ФИО ВК хранит еще тексты некоторых постов, личные сообщения, группы, статусы названия\продолжительность аудио и видеозаписей и много чего еще. Вы просто указали довольно точную цифру и я подумал, что где-то пропустил раскрытие архитектурных особенностей и статистических данных ВК.
Spanner, которую делал "Чак Норрис" мира программистов ) Использует какие-то сверхточные замеры времени с тиком в наносекунды. Но вообще все таки при выборе монго без шардинга, но с транзакциями или монго с шардингом, но с использованием двухфазного коммита (усложнение и замедление операций), то я бы выбрал второе. Хотя с другой стороны TokuMX (только что узнал о них от Вас, спасибо) позволяет использовать монгу для всего, но коллекции, которые должны использовать транзакции не шардить или использовать транзакции только на одной шарде (но тогда надо заставить монгу шардировать с учетом взаимных связок, чтобы пользователь и все его посты оказались на одном инстансе, а это фактически проработка архитектуры шардинга руками и мы снова возвращаемся к вопросу зачем нам монга).