|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
pkarklinавтор$connection = new Mongo(); $db = $connection->test; $time_start = microtime(); for($i=0;$i<=100000000;$i++) { $db->insert(array( 'a' => mt_rand(), 'b' => md5(chr(mt_rand(33,126))) )); } echo microtime() - $time_start; Интересно, что ЭТИМ пытались измерить... Этим? Это синтетический тест на время в PHP среде на вставку 100000000 строк в бд "test" , по два столбца в каждой, первый - int , второй - строка (хеш от рандомного символа). Привёл для сравнения, любой кто знает php напишет без проблем аналог для mysql. Естественно в зависимости от железа время будет различным. Можете добавить memory_get_usage() | memory_get_peak_usage() по вкусу. Ваш К.О. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2012, 00:04 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
pkarklinWol_fiдолжен тянуть сервер Intel® Core™ i7-2600 quad core... Чего, простите, Вы назвали сервером??? <b>физическим </b> сервером я назвал вот это - EX4 ; В качестве же вебсерверов - apache+nginx. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2012, 00:10 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
Wol_fiЭто синтетический тест на время Спрошу еще раз... Вы этим тестом пытались измерить что? Быстродействие чего? Wol_fiЕстественно в зависимости от железа время будет различным. Угу. А если еще и тест переписать, то и на порядки на одном и том же железе. авторсервером я назвал вот это Простите, но это не сервер... Давайте, еще айфоны сервером будем называть... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2012, 08:30 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
pkarklinавторсервером я назвал вот это Простите, но это не сервер... Давайте, еще айфоны сервером будем называть... Сервер (грубо говоря, слуга) - это то, что обслуживает кого-то/что-то. Отказоустойчивость, производительность и т.п. не имеют прямого отношения к делу. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2012, 08:38 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
Victor MetelitsaСервер (грубо говоря, слуга) - это то, что обслуживает кого-то/что-то. Отказоустойчивость, производительность и т.п. не имеют прямого отношения к делу. Да Вы что? Таки не имеет? А как же: Wol_fiКаждый запрос тянет финансовую транзакцию, которая тянет статистику и биллинг, то есть данные могут понадобится real-time до секунды (пользователя запросил выплату, или статистику), Не надо углубляться в терминологию в отрыве от темы! ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2012, 08:45 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
pkarklinVictor MetelitsaСервер (грубо говоря, слуга) - это то, что обслуживает кого-то/что-то. Отказоустойчивость, производительность и т.п. не имеют прямого отношения к делу. Да Вы что? Таки не имеет? А как же: "К делу" выяснения, сервер это или не сервер. Wol_fiКаждый запрос тянет финансовую транзакцию, которая тянет статистику и биллинг, то есть данные могут понадобится real-time до секунды (пользователя запросил выплату, или статистику), Не надо углубляться в терминологию в отрыве от темы! Это сервер, характеристики которого вы считаете неподходящими для выполнения описанной в топике работы. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2012, 08:56 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
Victor MetelitsaЭто сервер, характеристики которого вы считаете неподходящими для выполнения описанной в топике работы. Он для любой работы - неподходящий. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2012, 08:59 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
FVMas полностью удовлетворяет Вашим условиям. Отличная документация прилагается. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2012, 09:32 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
Wol_fiА мускульные InnoDB и MyISAM очень частенько отказывают|ложатся при больших размерах, что в этом случае не очень хорошо. В отсутствии адекватного DBA откажут/лягут любые СУБД. pkarklinОн для любой работы - неподходящий. Зажрались Вы, батенька... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2012, 13:16 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovЗажрались Вы, батенька... Угу. Мне не нужен слуга, у которого, то рука болит, а то понос... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2012, 13:26 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
Wol_fiSERG1257пропущено... MySQL ибо оно уже стоит. ЛЮБАЯ другая субд это риск. пропущено... Могут или понадобятся решает заказчик и только он. Нормальный вменяемый пользователь поймет, если большими буквами будет написано что данные доступны только до последнего часа или минуты (минута уже достаточно хороший интервал буферизации) пропущено... В отличии от переделок софта, затраты на железо гораздо надежнее. Вероятность поймать проблемы после установки нового сервера (процессора, памяти, диска) конечно же есть, но она не сравнима с вероятностью огрести после установки патча или новой субд. И если заказчик на это не идет ТО ЗАКАЗЧИКА ДАННАЯ ПРОБЛЕМА НЕ ТРОГАЕТ. Признайтесь честно, вам захотелось потрогать этот MongoDB в условиях приближенных к боевым. Тонко:) Трогайте Код: php 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Вы видимо работаете в параллельной вселенной. Так как в этой адекватный заказчик, понимающий все тонкости попадается редко. Это к сожалению не такой случай. А мускульные InnoDB и MyISAM очень частенько отказывают|ложатся при больших размерах, что в этом случае не очень хорошо. Кстате какой здесь результат ? (ради интереса) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2012, 18:48 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
pkarklinDimitry SibiryakovЗажрались Вы, батенька... Угу. Мне не нужен слуга, у которого, то рука болит, а то понос... говнокода меньше писать надо ... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2012, 19:22 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
Bazistpkarklinпропущено... Угу. Мне не нужен слуга, у которого, то рука болит, а то понос... говнокода меньше писать надо ... Да просто задачи другого масштаба. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2012, 19:36 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
Bazist, Поучи меня еще, ага... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2012, 20:08 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
RENaissanceBazistпропущено... говнокода меньше писать надо ... Да просто задачи другого масштаба. скорей понты другого масштаба, нужно приземленней смотреть на вещи. Вполне себе оборотистый восьмиядерный проц, оперативы много, винт пишет 100мб в секунду. Что такое для такого сервака какието 200-300 вставок в секунду ? Теоретический предел его 200-300 ТЫСЯЧ вставок в секунду, но конечно на определенном ПО, на какойто непопсовой СУБД знающей толк в производительности. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2012, 20:52 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
Alexander RyndinКакая-то прям мода на MongoDB. Коллективное помешательство. :) Пройдет. Главное - ее попробовать. Не сразу, но пройдет. Как ВНЕЗАПНО ВДРУГ данные исчезнут. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2012, 20:54 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
BazistСУБД знающей толк в производительности. СУБД решают не только задачи производительности, как это не парадоксально. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2012, 20:54 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
pkarklinBazistСУБД знающей толк в производительности. СУБД решают не только задачи производительности, как это не парадоксально. СУБД много чего решают. И то что нужно и то что не нужно. Знаем, видели, наслышаны. То что можно было бы выписать с десятком строчек на каком нибудь оперативном языке приходится городить иногда таким вот огородом, например Код: sql 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. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325.
А потом мы говорим, что сервер такойто нам уже и не сервер ... Вообщемто это офтоп, но всегда нужно понимать что не железо отыгрывает первую роль, а как раз софт. Правильно нужно подбирать инструменты, а не пинать конфигурации серверов, потому что ваш любимый дистрибутив в состоянии покоя уже сотни мегабайт отжирает. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2012, 21:02 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
BazistТо что можно было бы выписать с десятком строчек на каком нибудь оперативном языке приходится городить иногда таким вот огородом, например Угу. Именно такие огороды и позволяют добиться максимального быстродействия при обработке реляционных данных, а не "оперативные языки". Bazistно всегда нужно понимать что не железо отыгрывает первую роль, а как раз софт. Первую роль всегда играет сбаллансированность системы, ибо стебельку не место на HP DL 980 G7, а MS SQL на калькуляторе MK-61. BazistПравильно нужно подбирать инструменты Спасибо, у меня с этим нет проблем. Если Вы хотите об этом поговорить, то не со мной. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2012, 21:15 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
pkarklinBazistТо что можно было бы выписать с десятком строчек на каком нибудь оперативном языке приходится городить иногда таким вот огородом, например Угу. Именно такие огороды и позволяют добиться максимального быстродействия при обработке реляционных данных, а не "оперативные языки". Иногда запросы нужно читать, а не форматирование разглядывать. Этот запрос иллюстрация всей уродливости реляционной системы, когда пытаются решить императивные задачи. Получается долго, длинно, медленно, с известными неисправимыми багами .... pkarklinBazistно всегда нужно понимать что не железо отыгрывает первую роль, а как раз софт. Первую роль всегда играет сбаллансированность системы, ибо стебельку не место на HP DL 980 G7, а MS SQL на калькуляторе MK-61. Совершенно с вами согласен. Осталось вам только обосновать, что для задачи ТС действительно необходим MS SQL. Он не будет выглядеть как пригнанный экскаватор на грядку петрушки требующий HP DL 980 G7. Повторюсь, какая нибудь легковесная база будет в сотни раз быстрее работать, даже на классических задачах. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2012, 12:34 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
BazistЭтот запрос иллюстрация всей уродливости реляционной системы, когда пытаются решить императивные задачи. Получается долго, длинно, медленно, с известными неисправимыми багами .... В подавляющем большинстве случаев уродливой реляционную модель делают кривые руки проектировщиков\разработчиков. BazistОсталось вам только обосновать, что для задачи ТС действительно необходим MS SQL. Я (или кто-то другой в этом топике) где-то предлагал ТС MS SQL?! BazistОн не будет выглядеть как пригнанный экскаватор на грядку петрушки требующий HP DL 980 G7. Повторюсь, какая нибудь легковесная база будет в сотни раз быстрее работать, даже на классических задачах. Пожалуйста, решите аналогичную задачу в многопользовательском режиме (когда 1 000 пользователей делают проводки) с сохранением консистентности. А так же решите каку-нибудь расчетную задачу, в которой была бы и запись и чтение в одной транзакции. И чтоб посередине вашего расчета уборщица выдернула шнур питания из Вашего "сервера". ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2012, 14:16 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
BazistИногда запросы нужно читать, а не форматирование разглядывать. Этот запрос иллюстрация всей уродливости реляционной системы, когда пытаются решить императивные задачи. Не нужно пытаться обосновать кривость своей архитектуры, якобы, недостатками реляционной модели. Задачи, которые не предназначения для SQL, всегда можно вынести в отдельный слой, что позволяет большинство современных СУБД. Ну а если разрабатывать задачу в стиле "Что вижу, о том пою", плюс забивать гору костылей, то да, получает так, как вы и сказали: BazistПолучается долго, длинно, медленно, с известными неисправимыми багами .... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2012, 14:28 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
pkarklinЯ (или кто-то другой в этом топике) где-то предлагал ТС MS SQL?! Тогда осталось непонятно как было определено что сервер для этой задачи слабый. Какая СУБД имелась ввиду на этом сервере ? pkarklinПожалуйста, решите аналогичную задачу в многопользовательском режиме (когда 1 000 пользователей делают проводки) с сохранением консистентности. А так же решите каку-нибудь расчетную задачу, в которой была бы и запись и чтение в одной транзакции. И чтоб посередине вашего расчета уборщица выдернула шнур питания из Вашего "сервера". Решать эту задачу я не буду. У меня нет 1000 пользователей делающих одновременно проводки и нет уборщицы которая выдергивает неожиданно шнур. Искренне надеюсь что 99% ресурсов обычная СУБД тратит в этой задачи на блокировки, консистенцию данных, рассылку почты, секьюрити, статистику (что там еще есть, напомните ?), а 1% тратит собственно на саму задачу продовок. Тогда по скоростям все впринципе сходится. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2012, 14:28 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
RENaissanceBazistИногда запросы нужно читать, а не форматирование разглядывать. Этот запрос иллюстрация всей уродливости реляционной системы, когда пытаются решить императивные задачи. Не нужно пытаться обосновать кривость своей архитектуры, якобы, недостатками реляционной модели. Задачи, которые не предназначения для SQL, всегда можно вынести в отдельный слой, что позволяет большинство современных СУБД. Ну а если разрабатывать задачу в стиле "Что вижу, о том пою", плюс забивать гору костылей, то да, получает так, как вы и сказали: BazistПолучается долго, длинно, медленно, с известными неисправимыми багами .... О каком слое идет речь ? Речь идет о жонглировании временными таблицами и курсорами ? Вы разобрались хоть что делает эта функция ? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2012, 14:35 |
|
Посоветуйте СУБД
|
|||
---|---|---|---|
#18+
BazistТогда осталось непонятно как было определено что сервер для этой задачи слабый. Какая СУБД имелась ввиду на этом сервере ? Я где-то сказал, что этот сервер "слабый"?! Помоему, Вы начинаете домысливать за меня... Я уже достаточно на мой взгляд, обосновал, что не может железяка с процем для десктопов и софверным раидом на двух винтах, купленных на Митинском радиорынке, называться сервером. Вы не догадываетесь, почему? Как Вы думаете, почему HDD того же объема и скорости для SAN стоит на порядок дороже? авторИскренне надеюсь что 99% ресурсов обычная СУБД тратит в этой задачи на блокировки, консистенцию данных, рассылку почты, секьюрити, статистику, а 1% тратит собственно на саму задачу продовок. Тогда по скоростям все впринципе сходится. Совершенно верно. Поэтому какое-либо сравнение Вашего детища с промышленными СУБД в части быстродействия не имеет смысла. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2012, 14:39 |
|
|
start [/forum/topic.php?fid=35&msg=37741349&tid=1552566]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
32ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 255ms |
total: | 387ms |
0 / 0 |