|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
stopв одном джисоне.Который тоже не очень-то "заточен на минимизацию трафика" :) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 17:08 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
miksoftstopв одном джисоне.Который тоже не очень-то "заточен на минимизацию трафика" :) В зазипованном джисоне! :) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 17:14 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
20 штВ зазипованном джисоне! :)Это можно и к СУБД сжатие трафика прикрутить. Тот же OpenVPN умеет. А специализированные решения жмут еще лучше, хотя изрядно дорогие. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 17:21 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
miksoft, Как сказал Дмитрий против высокой латентности канала это бесполезно. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 17:24 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
Симонов Денисmiksoft, Как сказал Дмитрий против высокой латентности канала это бесполезно.Это понятно, против нее все бесполезно, если передавать через канал интерактивные данные. В т.ч. и "джисон". ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 17:29 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
miksoftСимонов Денисmiksoft, Как сказал Дмитрий против высокой латентности канала это бесполезно.Это понятно, против нее все бесполезно, если передавать через канал интерактивные данные. В т.ч. и "джисон". Ну если вы будете на стороне базы данных из таблиц собирать джисоны, то может чтото и получится. Про Джисон я сказал, потому что Иерархия явно лучше минимизирует и представляет данные для передачи по сети, в отличии от типизированых таблицы с их датасетами. Пакет с джисончиком для Днипры может состоять всего из нескольких байт и делать какойто мелкий апдейт. Селект пользователя из базы, (симбиоз данных из примерно 20 таблиц еслиб они были в таблицах) занимает 2.3 кб. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 18:54 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
stop, привет как сам? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 19:24 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
maytonstop, привет как сам? Привет, норм. Пилю по мере возмжностей крупный проект на Днипре, вычищаю баги. У тебя как справы ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 21:02 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
asphixТекущая поделка на Access 2007 Значит база < 2Gb. Посмотрите в сторону MS SQL Server 2014 Express Edition. И переход будет проще, и доп. нишнтяков поимеете (Reporting, FTS). Переносите по максимуму обработку данных на серверную сторону (хп). Клиент может остаться и на дельфе, хотя, его все равно придеться переписывать. Компоненты доступа к данным в принципе без разницы какие (если клиент будет дергать хп с сервера), лишь бы они вас устраивали по уровню совместимости с версией сервера в части поддерживаемых нововведений. Кстати, дельфа то какая? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 21:26 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
stopПро Джисон я сказал, потому что Иерархия явно лучше минимизирует и представляет данные для передачи по сети, в отличии от типизированых таблицы с их датасетами. Пакет с джисончиком для Днипры может состоять всего из нескольких байт и делать какойто мелкий апдейт. Селект пользователя из базы, (симбиоз данных из примерно 20 таблиц еслиб они были в таблицах) занимает 2.3 кб. Гм... Каким образом минимизирует? Зачем передавать всю иерархию по сети? Ну, вот классическое дерево. Пусть там на листьевом уровне будет 1 000 000 элементов. Показали пользователю первый уровень, состоящий, ну, скажем, из 10 узлов, показав признак наличия "детей" плюсиком, там где есть дети. Запросик будет простой, результат плоский, трафик минимальный. Будет пользователь кликать по плюсикам, будем подтягивать данные, выполняя все тот же самый серверный код. Вы готовы заранее предугадать, какой плюсик кликнет пользователь, чтобы тащить нужный кусок иерархии? Или не доводилось работать с большим кол-вом детей? Это не сраказм и не наезд. Просто пытаюсь понять, как джисон мне сможет здесь помочь, заменив точеченые обращения к бд с получением результата в TDS. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 21:36 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
miksoftА специализированные решения жмут еще лучше, хотя изрядно дорогие. Сложно говорить о дорогих специализированных решениях, когда заявленный автором канал - 128 КБит. Кстати, интересно, какой он в смысле физики... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 21:51 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
pkarklinstopПро Джисон я сказал, потому что Иерархия явно лучше минимизирует и представляет данные для передачи по сети, в отличии от типизированых таблицы с их датасетами. Пакет с джисончиком для Днипры может состоять всего из нескольких байт и делать какойто мелкий апдейт. Селект пользователя из базы, (симбиоз данных из примерно 20 таблиц еслиб они были в таблицах) занимает 2.3 кб. Гм... Каким образом минимизирует? Зачем передавать всю иерархию по сети? Ну, вот классическое дерево. Пусть там на листьевом уровне будет 1 000 000 элементов. Показали пользователю первый уровень, состоящий, ну, скажем, из 10 узлов, показав признак наличия "детей" плюсиком, там где есть дети. Запросик будет простой, результат плоский, трафик минимальный. Будет пользователь кликать по плюсикам, будем подтягивать данные, выполняя все тот же самый серверный код. Вы готовы заранее предугадать, какой плюсик кликнет пользователь, чтобы тащить нужный кусок иерархии? Или не доводилось работать с большим кол-вом детей? Это не сраказм и не наезд. Просто пытаюсь понять, как джисон мне сможет здесь помочь, заменив точеченые обращения к бд с получением результата в TDS. Вы не совсем поняли суть того, о чем я говорил. Если в джисоне (иерархии) можно представить обьект вот так, и вернуть его за один запрос Код: c# 1. 2. 3. 4.
То в реляционке все делается через джоин membertype1type2type3type4type5type6type7type8type9type10type Конечно, можно попытаться сделать два запроса (опять же трафик и латентность канала). Может быть чтото попытается сжать сам провайдер RDBMS, но суть остается сутью. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 22:01 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
Ну и разница в размере пакета, даже на таком простом примере уже в 2 раза. Плюс MSSQL/Postgres еще чтото своего передаст о типах данных в столбцах и их размерах, плюс еще служебных полей напихает, короче размер еще увеличится по сравнению с джисон. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 22:09 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
pkarklinКстати, интересно, какой он в смысле физики...С обоих (со всех, если их больше двух) концов канала стоит специальная железяка. Она умеет обучаться по проходящему трафику и накапливать статистику, по которой составляется частотный словарь для пакетов. При дальнейшей работе, когда нужно передать уже переданный ранее пакет (или данные прикладного протокола), передается только его номер по словарю. Железяки умеют работать как на уровне TCP/IP, так и на уровне ряда прикладных протоколов (в т.ч. SMB). Понимают ли они протоколы СУБД - не знаю. Естественно, пускать шифрованный VPN поверх такого канала неэффективно, ибо почти всегда будут промахи мимо словаря. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 22:11 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
stop, авторТо в реляционке все делается через джоин Ах, вон Вы про что. Это сгодится, когда количество type ограничено десятками. В этом случае для лукапа выполнить один отдельный запрос. Если кол-во значений в type будет большим, как будет это выглядеть? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 22:12 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
miksoftpkarklinКстати, интересно, какой он в смысле физики...С обоих (со всех, если их больше двух) концов канала стоит специальная железяка. Она умеет обучаться по проходящему трафику и накапливать статистику, по которой составляется частотный словарь для пакетов. При дальнейшей работе, когда нужно передать уже переданный ранее пакет (или данные прикладного протокола), передается только его номер по словарю. Железяки умеют работать как на уровне TCP/IP, так и на уровне ряда прикладных протоколов (в т.ч. SMB). Понимают ли они протоколы СУБД - не знаю. Естественно, пускать шифрованный VPN поверх такого канала неэффективно, ибо почти всегда будут промахи мимо словаря. Прошу прощения, что я не правильно выразился и Вы меня неправильно поняли. Про физику я спрашивал в плане канала у ТС, а не о "специальных железяках". ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 22:15 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
stopЕсли в джисоне (иерархии) можно представить обьект вот так, и вернуть его за один запрос Код: c# 1. 2. 3. 4.
То в реляционке все делается через джоин membertype1type2type3type4type5type6type7type8type9type10typeВ SQL тоже можно сериализовать (в т.ч. частично) результат и получить такую выборку: memberstype1,2,3,4,5,6,7,8,9,10type ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 22:16 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
stopНу и разница в размере пакета, даже на таком простом примере уже в 2 раза. 4K - это дефолтный размер пакета, который можно уменьшить до 512 для систем, неиспользующих bulk операции и обменивающимися малыми порциями данных. Ну, или увеличить до 16,383. stopПлюс MSSQL/Postgres еще чтото своего передаст о типах данных в столбцах и их размерах, плюс еще служебных полей напихает, короче размер еще увеличится по сравнению с джисон. Это легко можно проверить, в части размера трафика. Передача метаданных с данными - это одна из полезных фич, ибо понять без метаданных, что такое 20160512 невозможно. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 22:20 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
pkarklinstop, авторТо в реляционке все делается через джоин Ах, вон Вы про что. Это сгодится, когда количество type ограничено десятками. В этом случае для лукапа выполнить один отдельный запрос. Если кол-во значений в type будет большим, как будет это выглядеть? А как будет выглядеть таблица, если джоинов будет не один, а допустим с 10-15 таблицами что ближе к реальности ? Вот например, мой джисончик сущности User Код: c# 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. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275.
Здесь гдето 2-3 кб данных если сериализовать. Как это через таблицы вытянуть, какой трафик будет ? Или опять на запросы дробить, что еще более смертельно для слабых каналов связи. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 22:21 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
stop, Сериализовывать в json сейчас все умеют... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 22:25 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
stopПлюс MSSQL/Postgres еще чтото своего передаст о типах данных в столбцах и их размерах, плюс еще служебных полей напихает, короче размер еще увеличится по сравнению с джисон."Джисон" тоже не по голому TCP/IP обычно передается. Т.е. тоже HTTP-оверхэд присутствует. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 22:28 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
stop, авторА как будет выглядеть таблица, если джоинов будет не один, а допустим с 10-15 таблицами что ближе к реальности ? 10-15 справочников в одном выносе? В части BI в плане звезды я еще могу представить такое. В транзакционной системе - нет. авторВот например, мой джисончик сущности User Много как-то букв. Если Вы по-русски опищите, что он делает, то я по возможности постараюсь оценить объем трафика. С Вас физическая модель данных только. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 22:29 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
pkarklinstop, авторА как будет выглядеть таблица, если джоинов будет не один, а допустим с 10-15 таблицами что ближе к реальности ? 10-15 справочников в одном выносе? В части BI в плане звезды я еще могу представить такое. В транзакционной системе - нет. Открытие даже какой нибудь самой простой учетной системы генерит обращение к десяткам таблиц уже при просто ее открытии. В самой базе же могут быть сотни таблиц. pkarklinМного как-то букв. Если Вы по-русски опищите, что он делает, то я по возможности постараюсь оценить объем трафика. С Вас физическая модель данных только. Там не на русском, там на С# готовая модель данных, которую можно запихнуть в какую нибудь ORM и оценить количество сгенерированых таблиц а также размер трафика, когда эту модельку нужно натянуть на вьюшку. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 22:38 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
stop, И я, к сожалению, не получил ответа на этот вопрос: авторЕсли кол-во значений в type будет большим, как будет это выглядеть? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 22:39 |
|
Выбор СУБД для медленного канала
|
|||
---|---|---|---|
#18+
miksoftstopПлюс MSSQL/Postgres еще чтото своего передаст о типах данных в столбцах и их размерах, плюс еще служебных полей напихает, короче размер еще увеличится по сравнению с джисон."Джисон" тоже не по голому TCP/IP обычно передается. Т.е. тоже HTTP-оверхэд присутствует. Смотря где. В мой СУБД джисон пишется прямо в сокет, следовательно оверхед там считаные байты. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2016, 22:40 |
|
|
start [/forum/topic.php?fid=35&msg=39234681&tid=1552265]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
58ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 177ms |
0 / 0 |