Александр Павлюк,
обычный селект из tarantool.... прямо по их гайду ;-))
fmt.Printf("%T\n", resp.Data[0])
s := resp.Data[0].([]interface{})
fmt.Println(s[0])
fmt.Println(s[1])
[]interface {}
99999
sss
да. я получил то что хотел... но чтож так сложно то.. ;((
огромное вам спасибо
Александр Павлюк,
./test.go:133:17: invalid argument resp.Data[0] (type interface {}) for len
./test.go:134:26: invalid operation: resp.Data[0][0] (type interface {} does not support indexing)
./test.go:135:26: invalid operation: resp.Data[0][1] (type interface {} does not support indexing)
Как то странно..
Логично предположить что у строки abc должен быть определенный хэш.. А тут оказывается что захотелось мне взять первую цифру - и хэш стал -5434086359492102041.. а захотелось взять вторую цифру и хэш все той же строки abc стал 4297124817637354834...
Что за нечеткая логика? ;-)
сейчас на mysql на tokudb load data in file ignore инсертит около 20-40т строк в секунду. этого хватает. удалений нет. а вот селекты перестали "удовлетворять"
все бд, даже пресловутая монга дает доступ - вопрос в скорости и необходимости индексации
нужен доступ постоянно к любым данным в базе. то есть нет небольшой области "горячих" данных. все миллиарды данных равнозначны и к любой строке нужен максимально быстрый доступ.
выборки осуществляются по хэшу - я так понимаю индекс по этому столбцу всяко будет сделан
тут вообще непонятно о чем речь, то ли о шардинге, то ли о репликации
о шардинге
естественно важна скорость выборки по случайному(существующему в базе) хэшу.
lega: от 1 до 254. выборки по хэшу. хэш расчитывается внешней программой и в базу заносится просто как цифра. естественно у одинакового текста одинаковый хэш (хэши в базе уникальны (про коллизии знаю - они не важны))
Разбил файл на 10 кусков. Отсортировал каждый по отдельности.. А чем их "смержить?" Все крутится под linux. У команды sort есть режим merge (sort -m), но получается что 10 сортированных кусков просто собрались в один файл который естественно не отсортирован.
"незначительное" количество коллизий - приемлемо
UNSIGNED INT в mysql это всего 4294967295 вариантов - при миллиарде записей количество коллизий будет просто адское.
получается что использовать UNSIGNED INT нельзя.
верно я размышляю?
так как же быть?
обычный селект из tarantool.... прямо по их гайду ;-))
fmt.Printf("%T\n", resp.Data[0])
s := resp.Data[0].([]interface{})
fmt.Println(s[0])
fmt.Println(s[1])
[]interface {}
99999
sss
да. я получил то что хотел... но чтож так сложно то.. ;((
огромное вам спасибо