По поводу прочитанных сообщений — это видно внутри диалога. Непрочитанные сообщения помечаются другим цветом. В управлении перепиской примерно тот же принцип.
А насчет последних сообщений есть небольшая проблема. Хотели сделать как в gmail, чтобы кто последний ответил, тот и в списке участников последний. Но с этим есть проблема выборки по скорости — приложение попросту тормозит. Пока думаем как это можно сделать.
Простота плоха тем, что привлекает в область много профанов, которые считают, что научились программировать после того как сделали свой первый сайт. Этим же плохи современные доступные по цене зеркалки.
> Да, у PHP сейчас лучший менеджер зависимостей из всех языков.
говорить так и менеджере зависимостей, который был inspired by npm — это по крайней мере смешно
> PHP все еще является наипростейшим языком для изучения не-техническими людьми
и именно это же является одной из его слабых сторон
> Давайте я вам рассскажу маленький секрет успеха PHP
нет, спасибо
Я пожалуй спрошу здесь, потому что кому-то это может быть полезно.
В проекте, над которым я работал около трех лет (сейчас с ним работает как раз Makaveli), у нас максимальное количество документов в одной БД — около 112К, видов из них строится достаточно много. Во всяком случае я не совру, если скажу, что есть несколько видов >1М записей в каждом.
Конечно же у нас есть небольшой допинг в виде простой прослойки memcached (https://github.com/1999/couchdb-php), но это разумеется лишь уменьшает количество SELECT-запросов к CouchDB, хоть и радикально. Но я точно помню, что проблем с производительностью выборок у нас не было даже когда количество документов в виде превышало 1М. Другой вопрос — разумеется мы столкнулись с провисанием производительности при INSERT и дальнейшем перестроении выборки при сложном reduce, о чем я написал в своей статье. Но это и логично, страшного в этом ничего не было. Небольшая оптимизация reduce, изменение логики и все встало на места. Во всяком случае потом, когда в нашу БД добавлялся документ и перестраивалась выборка, провисания я никогда не замечал. Ведь в этом же и суть видов CouchDB, что один документ не должен влиять на другие, то есть при внесении одного документа (или же его обновлении), map-функция будет запускаться для него одного.
Если то, о чем вы говорите, правда (кол-во документов >2М затормаживает работу), то о таком бы трубили на каждом шагу, БД была бы попросту не production-ready. Это даже ведь не хайлоад (это немножко не то понятие, но суть понятна). Но вот наш пример — у нас на таких количествах в выборках (не в БД) все было ок. Может быть просто вы говорите несколько о других кейсах? Приведу пару примеров из вашей статьи:
> Порой у нас около 2 млн. обновлений базы (около 1 млн. документов в дереве) и работает вполне сносно, но появляется ещё 100 тысяч, и производительность вылетает в трубу
> Например, вы используете CouchDB, чтобы хранить документы с низкой продолжительностью жизни (сессии, lock-файлы, очереди)
> работая с CouchDB 2 года, я могу сказать, что я до сих пор не знаю, есть ли такая ситуация, где нужно использовать именно CouchDB, а не другие базы.
Мне кажется ваши тесты немного не на ту тему. CouchDB — потрясающе простые выборки и потрясающе медленные (конечно же по сравнению с SELECT) внесения и обновления. Именно поэтому сессии, очереди и пр. — ни в коем случае нельзя хранить в CouchDB. И график из той же статьи — он может возникать, когда происходит массовое обновление документов в БД. Живой пример, который приходит мне в голову — nested sets, которые берут программисты при реализации веток комментариев на SQL. Но при работе в CouchDB занесение одного комментария не должно влиять на другие документы, ведь в этом и суть. Потому в нашем проекте мы написали собственную древовидную структуру, которая работала (и работает) на ура при достаточно большом количестве документов и объеме выборок.
> производительность неожиданно начинает сильно хромать на ЛЮБЫЕ операции
Главный вопрос: вы в этом уверены? Если соотношение выборок к записям составляет 100 и выше, то такого не должно быть.
Добрый день, я к сожалению не до конца помню структуру БД, но суть в том, что события могли быть двух типов:
1. те, которые происходят в определенные дни недели с N1 числ по N1 число
2. вобще точечные, например во вторник, четверг на этой неделе и через 2 месяца еще в среду 4 июня.
Выборка событий необходима по сути за день, то есть в качестве ключа неделю передать — это мало. События не просто периодические и идут сами по себе — они еще имеют дату начала (+ время) и дату окончания (+ время). Поэтому было принято решение создавать документ события с датами его проведения (даты — поле, массив), то есть генерация дат по факту создания документа. Чтобы прояснить: под генерацией дат я имею в виду вид, который обходит документы и emit-ит в итоговую выборку данные с ключами равными дате проведения события.
Осталось узнать какова производительность этого, гм, фреймворка. Пока чем-то напоминает как раз тот самый reduce.
Думаю вы зря так про js с Map-Reduce, правда я его использую в CouchDB и там не ad-hoc.
> Вариантов дальнейших действий два — или найти новый, пока еще не раскрученный файлообменник и использовать его, пока он не испортится, или организовать собственное решение
Вобще есть еще третий — платить за использование сервиса. Странно, что вы о нем забыли.
А насчет последних сообщений есть небольшая проблема. Хотели сделать как в gmail, чтобы кто последний ответил, тот и в списке участников последний. Но с этим есть проблема выборки по скорости — приложение попросту тормозит. Пока думаем как это можно сделать.
говорить так и менеджере зависимостей, который был inspired by npm — это по крайней мере смешно
> PHP все еще является наипростейшим языком для изучения не-техническими людьми
и именно это же является одной из его слабых сторон
> Давайте я вам рассскажу маленький секрет успеха PHP
нет, спасибо
www.google.com/search?q=sasha&um=1&ie=UTF-8&hl=en&tbm=isch&source=og&sa=N&tab=wi
В проекте, над которым я работал около трех лет (сейчас с ним работает как раз Makaveli), у нас максимальное количество документов в одной БД — около 112К, видов из них строится достаточно много. Во всяком случае я не совру, если скажу, что есть несколько видов >1М записей в каждом.
Конечно же у нас есть небольшой допинг в виде простой прослойки memcached (https://github.com/1999/couchdb-php), но это разумеется лишь уменьшает количество SELECT-запросов к CouchDB, хоть и радикально. Но я точно помню, что проблем с производительностью выборок у нас не было даже когда количество документов в виде превышало 1М. Другой вопрос — разумеется мы столкнулись с провисанием производительности при INSERT и дальнейшем перестроении выборки при сложном reduce, о чем я написал в своей статье. Но это и логично, страшного в этом ничего не было. Небольшая оптимизация reduce, изменение логики и все встало на места. Во всяком случае потом, когда в нашу БД добавлялся документ и перестраивалась выборка, провисания я никогда не замечал. Ведь в этом же и суть видов CouchDB, что один документ не должен влиять на другие, то есть при внесении одного документа (или же его обновлении), map-функция будет запускаться для него одного.
Если то, о чем вы говорите, правда (кол-во документов >2М затормаживает работу), то о таком бы трубили на каждом шагу, БД была бы попросту не production-ready. Это даже ведь не хайлоад (это немножко не то понятие, но суть понятна). Но вот наш пример — у нас на таких количествах в выборках (не в БД) все было ок. Может быть просто вы говорите несколько о других кейсах? Приведу пару примеров из вашей статьи:
> Порой у нас около 2 млн. обновлений базы (около 1 млн. документов в дереве) и работает вполне сносно, но появляется ещё 100 тысяч, и производительность вылетает в трубу
> Например, вы используете CouchDB, чтобы хранить документы с низкой продолжительностью жизни (сессии, lock-файлы, очереди)
> работая с CouchDB 2 года, я могу сказать, что я до сих пор не знаю, есть ли такая ситуация, где нужно использовать именно CouchDB, а не другие базы.
Мне кажется ваши тесты немного не на ту тему. CouchDB — потрясающе простые выборки и потрясающе медленные (конечно же по сравнению с SELECT) внесения и обновления. Именно поэтому сессии, очереди и пр. — ни в коем случае нельзя хранить в CouchDB. И график из той же статьи — он может возникать, когда происходит массовое обновление документов в БД. Живой пример, который приходит мне в голову — nested sets, которые берут программисты при реализации веток комментариев на SQL. Но при работе в CouchDB занесение одного комментария не должно влиять на другие документы, ведь в этом и суть. Потому в нашем проекте мы написали собственную древовидную структуру, которая работала (и работает) на ура при достаточно большом количестве документов и объеме выборок.
> производительность неожиданно начинает сильно хромать на ЛЮБЫЕ операции
Главный вопрос: вы в этом уверены? Если соотношение выборок к записям составляет 100 и выше, то такого не должно быть.
1. те, которые происходят в определенные дни недели с N1 числ по N1 число
2. вобще точечные, например во вторник, четверг на этой неделе и через 2 месяца еще в среду 4 июня.
Выборка событий необходима по сути за день, то есть в качестве ключа неделю передать — это мало. События не просто периодические и идут сами по себе — они еще имеют дату начала (+ время) и дату окончания (+ время). Поэтому было принято решение создавать документ события с датами его проведения (даты — поле, массив), то есть генерация дат по факту создания документа. Чтобы прояснить: под генерацией дат я имею в виду вид, который обходит документы и emit-ит в итоговую выборку данные с ключами равными дате проведения события.
Думаю вы зря так про js с Map-Reduce, правда я его использую в CouchDB и там не ad-hoc.
Вобще есть еще третий — платить за использование сервиса. Странно, что вы о нем забыли.