Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
сжатие CLOB
|
|||
|---|---|---|---|
|
#18+
есть таблица, есть пара полей CLOB содержащие большие объемы "повторяющейся" информации в каждой записи. есть желание при отдаче "наружу" на клиент через сеть гнать CLOB в сжатом виде и на клиенте разжимать - экономия трафика _очень_ существенная чтоб ради нее заморачиваться. может у кого есть наработка хранимой функции на жабе которая на входе принимает CLOB а на выходе выдает сжатый BLOB? Если жизнь так коротка, какой смысл куда-то спешить?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2008, 23:40 |
|
||
|
сжатие CLOB
|
|||
|---|---|---|---|
|
#18+
Сжатие/разжатие это ресурсоемкая операция, и применение в этом случае ява-хранимых может привести к излишнему потреблению мощностей. ИМХО лучше это реализовывать как External-функцию ну скажем на чистом C. Есть еще вариант, сделать SSL-туннель, т.к. в SSL есть алгоритмы для сжатия передаваемого потока данных. И это не потребует модификации прикладного ПО. Сжатием/расжатием будет заниматься транспорт. В DB2 есть собственная реализация работы по SSL, но пока не проверял поддерживается ли там сжатие, по идее должно. Сделать SSL-туннель несложно, методика достаточно хорошо описана в интернет-ресурсах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2008, 10:25 |
|
||
|
сжатие CLOB
|
|||
|---|---|---|---|
|
#18+
сжатие конечно ресурсоемко, но затраты по времени в сумме меньше чем толкать эти "тучные" CLOB вголую через узкий канал. просто после замеров под высокой нагрузкой когда происходят лаги узкое место именно ширина канала - часть клиентов висит на 32-64 кбит средней паршивости. проца хватает с запасом поэтому скорость сжатия не особо волнует (на данном этапе по крайне мере) ЗЫ. туннель пробовал - проблемы лезли из-за местных инфраструктурных тараканов на которую повлиять я не могу Если жизнь так коротка, какой смысл куда-то спешить?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2008, 12:26 |
|
||
|
сжатие CLOB
|
|||
|---|---|---|---|
|
#18+
ЗЫ2: сейчас клиенты с узким каналом сидят через VJDBC - но здесь тоже есть свои минусы Если жизнь так коротка, какой смысл куда-то спешить?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2008, 12:28 |
|
||
|
сжатие CLOB
|
|||
|---|---|---|---|
|
#18+
В таком случае делай функцию. Можешь для начала и на Java. Сами методики компрессии/декомпрессии встроены в JDK. Смотри классы в пакете java.util.zip. Если производительность/нагрузка на сервер будет устраивать, можно конечно так и оставить. Но помнить, что это может оказаться узким местом. А с туннелем какие проблемы возникли? Не хотят пропускать через брандмаузер? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2008, 12:53 |
|
||
|
сжатие CLOB
|
|||
|---|---|---|---|
|
#18+
сам код сжатия я накатаю - не проблема. меня в основном интересовало как правильно внутрь передать CLOB и наружу отдать BLOB - то бишь как параметры корректно объявить у функции. у нас каналы не свои - у прова свое железо и софт стоит хз какой. плюс у нас свое железо. и все опутано vipnet (спущен сверху). плюс большая территориальная разнесенность и как следствие разнощерстность железа. в сумме - тошнотворный коктейль. Если жизнь так коротка, какой смысл куда-то спешить?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2008, 13:15 |
|
||
|
сжатие CLOB
|
|||
|---|---|---|---|
|
#18+
По моему, тут задача чуточку неправильно поставлена... Вы хотите, чтобы сервер при отдаче данных сжимал CLOB в BLOB меньшего объема. Может быть, имеет смысл хранить в БД как CLOB так и готовый BLOB? Дело в том, что операций вставки идет значительно меньше, чем операций чтения записей... Или я ошибаюсь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2008, 13:46 |
|
||
|
сжатие CLOB
|
|||
|---|---|---|---|
|
#18+
есть сторонний софт который работает в том числе и с этой базой, заточен на CLOB и который переписывать никто не собирается. для себя я просто сделаю второй вариант хранимок (6 штук) которые отдают наружу вместо CLOB сжатые BLOB и все. и можно будет выбирать прямо на клиенте со сжатыми или нет данными работать "на ходу". по идее можно бы было хранить данные в сжатом виде и если нужны не сжатые CLOB то разжимать перед отдачей. но тут не факт что быстрее получится - содержимое CLOB обновляется (перегенерируется на сервере) в среднем раз в сутки практически по всем записям. а на клиент за те же сутки отдается от силы 2-3% из них. Если жизнь так коротка, какой смысл куда-то спешить?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2008, 14:01 |
|
||
|
сжатие CLOB
|
|||
|---|---|---|---|
|
#18+
Попробуйте: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2008, 19:11 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=35364065&tid=1603845]: |
0ms |
get settings: |
7ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
65ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
2ms |
| others: | 230ms |
| total: | 401ms |

| 0 / 0 |
