← Сtrl

ZZZ · Март 22, 2011 11:30:00

igor.kaist
что то не очень лестные отзывы слышал…

Очень зря. Вещь просто прекрасная, но нужно чётко определится с задачей.

igor.kaist · Март 22, 2011 11:42:54

ZZZ
Вещь просто прекрасная, но нужно чётко определится с задачей.

Вот с этим как раз проблемы :)
Мне нужно что нибудь прежде всего легкое, к условиям vds.
Текущая задача достаточно простая, сайтик с портфолио фотографа (меня). Категории, фотографии и прочие мелочи. Хочу что то типа этого:

{'type':'catalog','name':'wedding','photos':[photo1,photo2,photo3]}
{'type':'news','title':'Some title','photos':[photo2]}

{'type':'photo','url':'/images/1.jpg','title':'Some title'}

Понимаю, что можно тупо запиклить, все это дело. Но хочется сделать с пользой для себя, попутно изучая что то новое.

ZZZ · Март 22, 2011 12:38:51

Ну тогда лучше ZODB врядли можно что-нить придумать.
Но фотографии лучше на файловой держать и nginx'ом отдавать, а в БД держать только ссылки… Но думаю, что ты и без меня это знаешь. :-)

regall · Март 22, 2011 13:47:39

ZZZ
Ну тогда лучше ZODB врядли можно что-нить придумать.

Абсолютно согласен, для данной задачи - пэрсык!

o7412369815963 · Март 22, 2011 18:54:05

igor.kaist
Текущая задача достаточно простая, сайтик с портфолио фотографа (меня). Категории, фотографии и прочие мелочи. Хочу что то типа этого:
{'type':'catalog','name':'wedding','photos':[photo1,photo2,photo3]}
{'type':'news','title':'Some title','photos':[photo2]}
{'type':'photo','url':'/images/1.jpg','title':'Some title'}

в монго есть коллекции: не обязательно хранить тип:

db.catalog.save( {'name':'wedding','photos':[photo1,photo2,photo3]} )
db.news.save( {'title':'Some title','photos':[photo2]} )
db.photo.save( {'url':'/images/1.jpg','title':'Some title'} )

не понятно зачем фотки отдельно, их можно отдельно если например нужна возможность их комментирования, комментарии пихать в этот же документ, а вообще вариантов архитектур можно напридумывать много.
Если на какие-то объекты нет ссылок из нескольких мест (комменты, фотки, настройки, подписки…), то их желательно хранить внутри документа (владельца), что-б при открытии страницы клиентом, делать 1 запрос, что-бы достать всю нужную информацию.

По своему опыту пришел к выводу, что архитектуру нужно строить так, что-бы данные хранились в максимально готовом виде, + минимум запросов. - это похоже на кеширование - но это не оно.

Запуск программ из Python
Кодировки в python
Мой блог

igor.kaist · Март 22, 2011 23:31:20

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

Да, это уже детали. У меня, например, одна и та же фотография, может быть в нескольких местах. И в портфолио и в новости о событии. Один раз загрузил, вписал title и используй где хочешь.

o7412369815963
По своему опыту пришел к выводу, что архитектуру нужно строить так, что-бы данные хранились в максимально готовом виде

Вот тоже к этому начинаю приходить. Да и меньше время на разработку, а время это деньги.
И начал задумываться над тем, что не все ложиться в реляционные базы данных. Вернее положить то можно, но через задницу. Например, деревья не очень то хочется тянет там хранить, несмотря на то что это не сложно.
Попробую поставить MondoDB, посмотреть как оно будет есть оперативку. Если прожорливо, то ZODB.

crchemist · Март 23, 2011 00:22:10

Вибачте не втримався і таки відпишу про ZODB українською.
ZODB не дуже добрий вибір де мало оперативки. ZODB написана на пітоні, через це в неї купа пітонівських проблем. Страшенні проблеми з пам'яттю (з кешем), (проблеми проявляються в так званих borrowed references кеша крім яких переважно є звичайні референси, яких неможливо позбутись через Ghost objects) великі проблеми з багато-процесністю/потоковістю. Навіть використовуючи BTrees і розуміючи як вони працюють дуже легко зжерти всю оперативку, не спеціально перетворивши їх на список. Далеко не завжди вдається не перетворювати BTrees в списки (в сорсах plone є такі місця). Крім того є PersistentMapping який треба використовувати тільки в специфічних випадках. Дуже важко і так само не завжди можливо зробити щоб зобд жерла мало памяті і працювали швидко. А ще є Catalog - цікава штука, з ним проблем нема, але все ж таки вартує розібратись як він працює. Одне в ньому погано - все треба робити явно.

В ZODB один плюс - це простота.

Отредактировано (Март 23, 2011 00:30:21)

crchemist · Март 23, 2011 00:25:35

Всі проблеми ZODB дуже сильно проявляються в Plone. Для того щоб видалити одного користувача сайту треба весь контент сайту підняти в оперативку (через локальні ролі) і він вже на 95відсотків залишиться там назавжди (pickle cache + ghost objects). Розмір БД на диску росте від звичайних запитів просто так (через portal_factory), правда zodb pack допомагає.

PS. Я дуже люблю ZODB, багато її використовував і скоріше всього буду використовувати надалі.

Отредактировано (Март 23, 2011 01:07:00)

ZAN · Март 23, 2011 15:19:50

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

igor.kaist · Март 23, 2011 21:11:20

опс, ZODB лочится у меня, если со второго потока пытаться открыть… Юзаю FileStorage, что то не по себе как то стало…

Python-сообщество

Уведомления

#1 Март 22, 2011 11:30:00

MongoDB 1.8

#2 Март 22, 2011 11:42:54

MongoDB 1.8

#3 Март 22, 2011 12:38:51

MongoDB 1.8

#4 Март 22, 2011 13:47:39

MongoDB 1.8

#5 Март 22, 2011 18:54:05

MongoDB 1.8

#6 Март 22, 2011 23:31:20

MongoDB 1.8

#7 Март 23, 2011 00:22:10

MongoDB 1.8

#8 Март 23, 2011 00:25:35

MongoDB 1.8

#9 Март 23, 2011 15:19:50

MongoDB 1.8

#10 Март 23, 2011 21:11:20

MongoDB 1.8

Board footer