ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / Покритикуйте архитектуру
15 сообщений из 65, страница 3 из 3
  3  все
Покритикуйте архитектуру
    #37912451
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
BlazkowiczmaytonВероятность отказа ФС на несколько порядков меньше чем ДБМС.
Да, чего там мелочится. Не на несколько порядоков а на десятки и сотни порядоков надежнее. И двух фазный комит поддерживает. И файлы всегда до конца дописывает. И откаты делает с пол пинка.
Я всё прекрасно понимаю. Но думаю что для картинок (это в принципе объекты R/O) можно
создать компромиссное решение. В БД сохранять объект BFILE со всеми атрибутами.
Датами создания там... метаинформацией и т.д. Сами файлы - соотв. В файловой системе.
И подкорректировать скрипты бэкапов чтобы снималась согласованная копия БД
а картинки - как бог даст или хотябы через снапшоты LVM. +Если задаться
правилом что картинка создаётся 1 раз и никогда не измеяется и имя её
всегда уникально (sеquence) то коллизий при восстановлении быть не должно.

ФС даст хоршее ускорения для веб-сервера и снимет с БД ненужную нагрузку.

Вот как-то так.
...
Рейтинг: 0 / 0
10.08.2012, 16:00:26
| Ответить | Цитировать | Написать  
Покритикуйте архитектуру
    #37912465
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
КореецKostya IlyinovКартинки предполагается хранить в базе как БЛОБы.
плохое решение.

===== оно всегда было не плохое, а 50 на 50

база будет расти из-за картинок.

==== а из-за описания товара расти не будет? Зачем вам урезанная БД без картинок?

время транзакций увеличится пропорционально размеру картинки.
==== и чем это плохо? Это один из атрибутов товара.

Как бы оракл это оптимально не хранил все равно будет медленнее записи файлов на диск.
===== на сколько микросекунд?

1000*20*400Кб..

===== тут вы правы, XE ограничивает БД по размеру

Придется сжимать и обрабатывать фотки самому. Вот увидите.

==== это всегда надо делать
...
Рейтинг: 0 / 0
10.08.2012, 16:08:21
| Ответить | Цитировать | Написать  
Покритикуйте архитектуру
    #37912470
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
последний пункт - АвтоУменьшаете фотку до размера 1,5 килобайт. И даёте кнопу "Сохранить" "Отменить".
Это же не фото-сервис для 1600 х 1200
...
Рейтинг: 0 / 0
10.08.2012, 16:12:12
| Ответить | Цитировать | Написать  
Покритикуйте архитектуру
    #37912471
Kostya Ilyinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kostya Ilyinov
Участник
mayton,

Коллега - нечто подобное и замышляется. По сути, картинка в СУБД нужна лишь для полноты картины, но она там нужна. Читаться оттуда она будет в идеале единожды - на ФС и потом на СДН. Но изобретать транзакционность для ФС я не хотел бы, плюс придумывать стратегию резервирования и т.д. Есть база, есть бэкап - это все что нужно, ничего лишнего. По поводу производительности, картинки будут в отдельной таблице и в отдельном табличном пространстве, а в перспективе и на отдельном дисковом массиве, поэтому оверхэд должен быть минимальным. В целом картина вырисовывается, я просто хотел убедиться что не упустил ничего очевидного. Грабли будут, но уже по крайней мере знаешь откуда они вырастут.

Насчет хранения данных в С3 - может быть сейчас и сделаю так, но обязательно с прослойкой - в перспективе все-таки будет целесообразнее купить физический сервер и поставить стойку в Мельбурне, а не Амазон в Синге или Токио. Избалована публика местная временем отклика. Спасибо всем откликнувшимся, кроме Александр2 :-) - так и не раскрыл своего хода мысли, только заключение.
...
Рейтинг: 0 / 0
10.08.2012, 16:12:36
| Ответить | Цитировать | Написать  
Покритикуйте архитектуру
    #37912477
Kostya Ilyinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kostya Ilyinov
Участник
Petro123,

Обработка перед вставкой картинки обязательно будет - надо как минимум добавить водяной знак, и уменьшить - тут вы правы. Насчет хранения - см. выше, думаю в отдельном табличном пространстве на отдельном устройстве все будет нормалек.
...
Рейтинг: 0 / 0
10.08.2012, 16:14:28
| Ответить | Цитировать | Написать  
Покритикуйте архитектуру
    #37912526
Фотография schwa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
schwa
Участник
BlazkowiczschwaИмея на каждой странице с по парой десятков картинок,

Вы уже узнали сколько у автора их будет?

schwa с каждый новым заходом получаем кучу не нужных запросов к апп серверу и базе (пока не закэшировал клиент эти изображения и так для каждого нового пользователя).

Эээ, ну без серверного кэша, можно СУБД нагнуть запросами даже без блобов.

schwaМне вот проще взять nginx чем героически бороться с проблемами производительности, которые гарантировано возникнут.
Ну, тогда расскажите как вы делаете бэкапы и заботитесь о целостности состояний в базе и ФС. Транзакции как откатываете?
Ну бэкапятся периодически картинки просто и все.
Никаких операций кроме (удаления очень редко) над ними не производится т.е. они полностью иммутабл. В базе хранятся как id и дата загрузки + несколько технических полей. Картинок несколько сотен гигабайт, живут на отдельном сервере, отдаются nginx-ом. Полет нормальный.
Может сейчас что-то и получше накрутили, но эти уже не занимаюсь, но проблем никаких с этим не было.
...
Рейтинг: 0 / 0
10.08.2012, 16:37:36
| Ответить | Цитировать | Написать  
Покритикуйте архитектуру
    #37912607
Leonidv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonidv
Участник
Kostya IlyinovНасчет хранения данных в С3 - может быть сейчас и сделаю так, но обязательно с прослойкой - в перспективе все-таки будет целесообразнее купить физический сервер и поставить стойку в Мельбурне, а не Амазон в Синге или Токио. Избалована публика местная временем отклика. Спасибо всем откликнувшимся, кроме Александр2 :-) - так и не раскрыл своего хода мысли, только заключение.
Сервера сloudfront и сервера ec2 это не совсем одно и тоже.
http://aws.amazon.com/cloudfront/#details - есть и в Сиднее http://aws.amazon.com/cloudfront/whats-new/
А так преимуществ своего сервера перед CDN никакого нет. Только дороже выйдет и хуже, ПМСМ.
...
Рейтинг: 0 / 0
10.08.2012, 17:29:33
| Ответить | Цитировать | Написать  
Покритикуйте архитектуру
    #37912619
Kostya Ilyinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kostya Ilyinov
Участник
Leonidv,

Да, читал про местный эдж. Конечно в связке с ЕС2 работать должно все четко. Но со временем будет целесообразнее иметь свое железо, поэтому и их КлаудФрант по идее будет не проще чем другие решения от сторонних "чистых" CDN.
...
Рейтинг: 0 / 0
10.08.2012, 17:42:21
| Ответить | Цитировать | Написать  
Покритикуйте архитектуру
    #37912622
Kostya Ilyinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kostya Ilyinov
Участник
Kostya Ilyinov,

Свой сервер (веб/апп) для картинок будет только в крайнем случае использоваться - если на СДН нет такого файла, ессесно свой СДН не предполагается.
...
Рейтинг: 0 / 0
10.08.2012, 17:43:47
| Ответить | Цитировать | Написать  
Покритикуйте архитектуру
    #37912626
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
schwaНу бэкапятся периодически картинки просто и все.
Никаких операций кроме (удаления очень редко) над ними не производится т.е. они полностью иммутабл. В базе хранятся как id и дата загрузки + несколько технических полей. Картинок несколько сотен гигабайт, живут на отдельном сервере, отдаются nginx-ом. Полет нормальный.
Может сейчас что-то и получше накрутили, но эти уже не занимаюсь, но проблем никаких с этим не было.
Судя по тому что у автора темы картинки тоже не принципиально важные данные, то, вероятно, да, не страшно и потерять чего.
...
Рейтинг: 0 / 0
10.08.2012, 17:45:53
| Ответить | Цитировать | Написать  
Покритикуйте архитектуру
    #37912642
Kostya Ilyinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kostya Ilyinov
Участник
Blazkowicz,

Важные-важные! Собственно для удобства и надежности хранения СУБД в первую очередь и предполагается их класть в базу.
...
Рейтинг: 0 / 0
10.08.2012, 17:58:11
| Ответить | Цитировать | Написать  
Покритикуйте архитектуру
    #37912650
Leonidv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonidv
Участник
Kostya IlyinovLeonidv,

Да, читал про местный эдж. Конечно в связке с ЕС2 работать должно все четко. Но со временем будет целесообразнее иметь свое железо, поэтому и их КлаудФрант по идее будет не проще чем другие решения от сторонних "чистых" CDN.
А почему целесообразней?
...
Рейтинг: 0 / 0
10.08.2012, 18:03:36
| Ответить | Цитировать | Написать  
Покритикуйте архитектуру
    #37912654
Фотография Denis.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Denis.
Участник
Kostya Ilyinov,

а зачем картинки в базе ???
регишься в азуре, микрософт тебе дарит 12 виртуалок на год и очень дешевые блобы. Картинки заливаешь в блобы, если надо отдавать в разных форматах\с вотермарками\разных размеров итд - ресайзишь и кладешь в кеш в блобы. Отдельным процессом чистишь кеш по последнему времени доступа. Время достпуа к блобам линейное и очень быстрое. + репликация. Пишешь им письмо чтоб сняли ограничение на макс 12 инстансов, размер роли делаешь очень маленький, ночью оставляешь 2 днем включаешь 100 :). Итого у тебя картинки отдаются раундробингом 100ней виртуалок(в часы пиковых нагрузок)+ бесконечное дисковое пространство с линейным верменем доступа. Дешево(если трафика меньше 90 гб в месяц - вообще бесплатно), масштабируемо и надежно.
...
Рейтинг: 0 / 0
10.08.2012, 18:04:58
| Ответить | Цитировать | Написать  
Покритикуйте архитектуру
    #37912669
Kostya Ilyinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kostya Ilyinov
Участник
Leonidv,

По моим выкладкам купить неплохой сервер с 16 гигами памяти и быстрыми дисками будет стоить около 6 штук. По идее это можно поделить на 2 машины vmware и это все равно должно по производительности/времени отклика быть ощутимо лучше чем у амазона те же 8 гигов. 8 гиговая машина у амазона стоит около 800 в год + 10 центов в час (это только машина, сторадж и трафик - отдельно). http://aws.amazon.com/ec2/#instance Т.е. в год на одну машину уходит около 2 штук. Таким образом физическое железо становится не таким уж и дорогим. На первых порах лезть в железо смысла нет, а потом - вполне. Если где есть неточности/упущения, буду признателен за опыт.
...
Рейтинг: 0 / 0
10.08.2012, 18:13:20
| Ответить | Цитировать | Написать  
Покритикуйте архитектуру
    #37912670
Kostya Ilyinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kostya Ilyinov
Участник
Denis.,

Хмм почитаю, я читал там даже линукс можно крутить. Интересно, для Австралии их время отклика как будет сопоставимо с Сингапурским амазоном?
...
Рейтинг: 0 / 0
10.08.2012, 18:14:37
| Ответить | Цитировать | Написать  
15 сообщений из 65, страница 3 из 3
  3  все
Форумы / Java [игнор отключен] [закрыт для гостей] / Покритикуйте архитектуру
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&msg=37912654&tid=2131168]:
 0ms
get settings:
 15ms
get forum list:
 27ms
check forum access:
 7ms
check topic access:
 7ms
track hit:
 51ms
get topic data:
 20ms
get forum data:
 5ms
get page messages:
 90ms
get tp. blocked users:
 3ms
others: 340ms
total:  565ms
созд. / загр.: 565ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]