|
|
|
Cassandra. CQL. Феерия багов?
|
|||
|---|---|---|---|
|
#18+
Добрый день, товарищи. Cassandra 1.1.4 Как оказалось вставить то в нее быстро, а вот вынуть...ну не то чтобы тяжело, просто найти то, что вставил, потом невозможно. Я просто покажу вызовы CQL. Очень похоже на SQL. Ппц начинается внезапно при попытке запросить по диапазону ключей. в скрипте есть комменты. Код: plsql 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. Кто нибудь знает почему оно так работает? Это сырость самого CQL или вообще таков принцип самих NoSQL баз. получать данные тока через "=" Я хочу просто пройтись по логу записей и сделать группировку. Группировка будет самая разнообразная. Ее можно не рассматривать, все сводится к тому что первоначально мне просто необходимо делать запрос вида ID>N. Где N это номер айдишника на котором остановился подсчет последний раз, а ID уникально. А оно так себя ведет в примере Код: plsql 1. это ппц какой-то. Кто нибудь с ней работал? Что делаю не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2012, 12:44:59 |
|
||
|
Cassandra. CQL. Феерия багов?
|
|||
|---|---|---|---|
|
#18+
Проблема в том, что по умолчанию записи упорядочиваются не по ключу, а по хешу ключа, чтобы равномерно распределить данные по узлам кластера. Как говорит документация , в этом случае выборка по диапазону невозможна: Using the ordered partitioner allows range scans over rows. This means you can scan rows as though you were moving a cursor through a traditional index. For example, if your application has user names as the row key, you can scan rows for users whose names fall between Jake and Joe. This type of query is not possible with randomly partitioned row keys, since the keys are stored in the order of their MD5 hash (not sequentially). При использовании ByteOrderedPartitioner запросы работают корректно, но вместо этого рекомендуется построить индекс. Подробности в приведенной выше ссылке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2012, 18:03:40 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=37950039&tid=2130988]: |
0ms |
get settings: |
15ms |
get forum list: |
22ms |
check forum access: |
6ms |
check topic access: |
6ms |
track hit: |
57ms |
get topic data: |
17ms |
get forum data: |
5ms |
get page messages: |
66ms |
get tp. blocked users: |
3ms |
| others: | 369ms |
| total: | 566ms |

| 0 / 0 |
