Программирование ver 4.1

Вполне норм решение. Сомневаюсь что все темы с комментами весят больше 10 кб на сообщение. Можно хранить, например, последние 100 тыс. сообщений или последнюю тысячу тем. Это всего гиг или два. Вообще ни о чём.

ага. и в реальном времени обновлять этот кэш.

довольно дикое решение.

я вот кстати не понимаю. разве при нормальном дизайне базы данных есть разница большая тема или нет?

Вполне норм решение. Сомневаюсь что все темы с комментами весят больше 10 кб на сообщение. Можно хранить, например, последние 100 тыс. сообщений или последнюю тысячу тем. Это всего гиг или два. Вообще ни о чём.

ага. и в реальном времени обновлять этот кэш.

довольно дикое решение.

я вот кстати не понимаю. разве при нормальном дизайне базы данных есть разница большая тема или нет?

кстати то, что лагали только большие темы это вообще смех, разницы ведь не должно быть вообще никакой

Вполне норм решение. Сомневаюсь что все темы с комментами весят больше 10 кб на сообщение. Можно хранить, например, последние 100 тыс. сообщений или последнюю тысячу тем. Это всего гиг или два. Вообще ни о чём.

ага. и в реальном времени обновлять этот кэш.

довольно дикое решение.

я вот кстати не понимаю. разве при нормальном дизайне базы данных есть разница большая тема или нет?

кстати то, что лагали только большие темы это вообще смех, разницы ведь не должно быть вообще никакой

это все паджинация вашими майэскуэлями со ихним лимит/оффсетом

Вполне норм решение. Сомневаюсь что все темы с комментами весят больше 10 кб на сообщение. Можно хранить, например, последние 100 тыс. сообщений или последнюю тысячу тем. Это всего гиг или два. Вообще ни о чём.

ага. и в реальном времени обновлять этот кэш.

довольно дикое решение.

я вот кстати не понимаю. разве при нормальном дизайне базы данных есть разница большая тема или нет?

конечно есть

вариант 1) ракопрограммист не добавил нужные индексы - то тут всё очевидно, таблицы с большим количеством строк начинают дико лагать

вариант 2) программист добавил нужные индексы, но не все запросы отрабатывают с использованием оптимального плана (где-то работает фулскан или отрабатывает не лучший индекс, а потом идет сканирование большого объема строк) - в части запросов будут проблемы на больших объемах данных

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

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

 

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

http://habrahabr.ru/post/173345/

 

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

 

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

поддерживаю

ну гугл очки реально хуйня какая-то.

вообще не очень приятно говорить с уебком, который пялится в какие-то очки

http://habrahabr.ru/post/173345/

 

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

 

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

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

ну гугл очки реально хуйня какая-то.

вообще не очень приятно говорить с уебком, который пялится в какие-то очки

окей, херня

как и нокиа с виндофоном

 

давай теперь каждый напишет на главную своё мнение по-поводу гугл очков

давай 20 человек выступят на главное пд с трактатом на тему "нави - говно, и сейчас я объясню почему"

 

нахуя писать в категорию "гугл" и "гаджеты" своё субъективное мнение по-поводу какой-то технологии/вещи, если оно вообще нахуй никому не всралось, туда заходят читать новости про гугл, а не о том, что кому-то что-то понравилось или не понравилось, в статье новой информации - ноль, только аналитика о хуёвом маркетинге от лица программиста, seems legit

ну хабр тоже хуйня как бы

Вполне норм решение. Сомневаюсь что все темы с комментами весят больше 10 кб на сообщение. Можно хранить, например, последние 100 тыс. сообщений или последнюю тысячу тем. Это всего гиг или два. Вообще ни о чём.

ага. и в реальном времени обновлять этот кэш.

довольно дикое решение.

я вот кстати не понимаю. разве при нормальном дизайне базы данных есть разница большая тема или нет?

конечно есть

вариант 1) ракопрограммист не добавил нужные индексы - то тут всё очевидно, таблицы с большим количеством строк начинают дико лагать

вариант 2) программист добавил нужные индексы, но не все запросы отрабатывают с использованием оптимального плана (где-то работает фулскан или отрабатывает не лучший индекс, а потом идет сканирование большого объема строк) - в части запросов будут проблемы на больших объемах данных

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

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

 

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

Я думаю всё гораздо проще: Загружают все записи в массив (т.к. база не mysql, а кроме как limit ничем пользоваться не умеют ), а потом из всего массива выбирают посты для нужной страницы. По крайней мере это единственное объяснение, т.к. по большому счету выбор из базы 100 или 1000 элементов не ведет к линейному увеличению времени загрузки.

Где база не mysql ? На пд не mysql разве ?

может быть у них не сервер, а просто клиентская машина с сата винтом

У них сервер, стоит 16гб ОЗу, прцо не помню.

mysql+php+nginx+php-fpm

У них сервер, стоит 16гб ОЗу, прцо не помню.

mysql+php+nginx+php-fpm

какая разница сколько там озу, если винт не серверный

У них сервер, стоит 16гб ОЗу, прцо не помню.

mysql+php+nginx+php-fpm

какая разница сколько там озу, если винт не серверный

Если настроить майскул и нгникс, чтобы они не лезли на ХДД, то какая разница, какой ХДД

У них сервер, стоит 16гб ОЗу, прцо не помню.

mysql+php+nginx+php-fpm

какая разница сколько там озу, если винт не серверный

Если настроить майскул и нгникс, чтобы они не лезли на ХДД, то какая разница, какой ХДД

вся база в памяти?

вся база в памяти?

До первого отключения электричества :D

прошло 1.5 недели

а я уже ненавижу аналитика который со мной работает по проекту

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

мой начальник говорит что я на правильном пути по становлению в должности

Вполне норм решение. Сомневаюсь что все темы с комментами весят больше 10 кб на сообщение. Можно хранить, например, последние 100 тыс. сообщений или последнюю тысячу тем. Это всего гиг или два. Вообще ни о чём.

ага. и в реальном времени обновлять этот кэш.

довольно дикое решение.

я вот кстати не понимаю. разве при нормальном дизайне базы данных есть разница большая тема или нет?

кстати то, что лагали только большие темы это вообще смех, разницы ведь не должно быть вообще никакой

это все паджинация вашими майэскуэлями со ихним лимит/оффсетом

лимит/оффсет и вправду лагает, но не на 1000 же записей