我正在尝试执行以下查询：
SELECT COUNT(*) FROM ns123.foo WHERE ttl < 60 * 60 * 24
我从Aerospike AQL count(*) SQL 模拟脚本中找到了 lua 脚本来执行COUNT(*)
使用带有上述 LUA 脚本的 Python，我尝试将 UDF 与读取策略一起应用：
client.udf_put('aggr_functions.lua')
query = client.query('ns123', 'foo')
policy = {
'expressions':
exp.LT(exp.TTL(), 60 * 60 * 24).compile()
}
query.apply('aggr_functions', 'count_star', [])
records = query.results(policy)
print(records)
我被抛出：
Traceback (most recent call last):
...
records = query.results(policy)
exception.UnsupportedFeature: (16, 'AEROSPIKE_ERR_UNSUPPORTED_FEATURE', 'src/main/aerospike/aerospike_query.c', 348, False)
对 Python3.8 库和服务器使用 Aerospike 6.1.x。
我有一个现有的记录有两个箱我需要使用java客户端API添加第三个箱
val client = new AerospikeClient("localhost",3000)
val bin1 = new Bin("name", "John")
val bin2 = new Bin("age" , 33)
client.add(null, key,bin1,bin2)
现在我该如何添加第三个bin？
val bin3 = new Bin("phone" , "555555123123")
不确定如何解决这个问题.我在我的mac上运行了以下命令.
sudo pip安装aerospike
我安装了Lua
ld: library not found for -llua
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: command 'cc' failed with exit status 1
----------------------------------------
Cleaning up...
Command /usr/bin/python -c "import setuptools, tokenize;__file__='/private/tmp/pip_build_root/aerospike/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-CQ0_XS-record/install-record.txt --single-version-externally-managed --compile failed with error code 1 in /private/tmp/pip_build_root/aerospike
Traceback (most recent call last):
File "/usr/local/bin/pip", line 11, in <module>
sys.exit(main())
File "/Library/Python/2.7/site-packages/pip/__init__.py", line 185, in main
return command.main(cmd_args)
File "/Library/Python/2.7/site-packages/pip/basecommand.py", …众所周知,Aerospike服务器不支持某些数据类型,如Float.但它们是在客户端处理的.例如,版本1.0.40的Python客户端支持使用序列化的不支持的数据类型.
我想知道客户端在从服务器检索数据时如何处理这个问题.我的意思是客户端如何知道bin应该被反序列化并呈现给用户.
如果我使用的客户端语言不支持此功能,这将帮助我从客户端外部处理.
谢谢.
我是这两种技术的新手,所以需要一些指导
我有一个S3桶的大量图像(2000万,870GB),遗憾的是它没有想到密钥,这使得读取过程变慢(至少1s - 1.8s读取).我们计划将其迁移到更好的读取优化桶.
然后我遇到了aerospike,在一些文档中,我读到我们甚至可以将图像存储为airospike中的键值对中的blob.虽然存储消耗很高,但读取速度会比使用SSD集成的任何其他产品快.
是否建议使用Aerospike存储像S3这样的键,然后值将是相应的图像？有没有其他S3的替代品有更快的读取？
UDF开发背景
我使用的是Aerospike 3.5.12.最初,我远程编写了UDF,然后通过Java客户端的UDF注册方法将其注册到Aerospike.这种方法有点麻烦(每次更改需要重新注册),但有效.
后来,我发现在Aerospike服务器上直接编辑文件比较方便,位于/aerospike_dir/usr/udf/lua/myUdf.lua.这很方便.所做的更改是永久性的,即使在群集重启时也是如此(如果我没记错的话).
最近,我升级到3.6.1.我发现直接对/aerospike_dir/usr/udf/lua/myUdf.lua所做的更改会被Aerospike识别,直到群集重新启动.重新启动后,所有更改都将丢失,文件将恢复为其原始版本.
问题
这是正常行为吗？如何禁用此自动恢复功能？或者,如果我没有正确开发UDF,我应该如何处理它？
它说这里是塞式应尽量在温暖的模式下启动,这意味着复用相同的内存区域持有钥匙.相反,每次重新启动数据库时,所有密钥都会从SSD驱动器加载回来,如果不是几小时,则可能需要几十分钟.我在日志中看到的内容如下:
Oct 12 2015 03:24:11 GMT: INFO (config): (cfg.c::3234) Node id bb9e10daab0c902
Oct 12 2015 03:24:11 GMT: INFO (namespace): (namespace_cold.c::101) ns organic **beginning COLD start**
Oct 12 2015 03:24:11 GMT: INFO (drv_ssd): (drv_ssd.c::3607) opened device /dev/xvdb: usable size 322122547200, io-min-size 512
Oct 12 2015 03:24:11 GMT: INFO (drv_ssd): (drv_ssd.c::3681) shadow device /dev/xvdc is compatible with main device
Oct 12 2015 03:24:11 GMT: INFO (drv_ssd): (drv_ssd.c::1107) /dev/xvdb has 307200 wblocks of size 1048576
Oct 12 2015 03:24:11 GMT: INFO …我有一百万条记录.我想检索匹配相同模式的所有记录.
例如,我可能有:
id=4444?mode=mode1?fieldA=abc
id=4444?mode=mode1?fieldA=azerty
id=4444?mode=mode1?fieldA=qwerty
id=4444?mode=mode1?fieldA=foo
id=4444?mode=mode1?fieldA=bar
是否有可能在不事先知道fieldA？的值的情况下进行查询以获取所有上述记录？正则表达式中的这样的东西:
id=4444?mode=mode1?fieldA=[\w]*
谢谢你的时间.
根据此链接,我了解到当同一个密钥的并发操作请求太多时,会发生热键错误.
我目前的情况:
我有一个记录,每隔5-10秒会更新一次,我将有大约20台机器,每台每秒10K查询试图读取该记录
我们有一个系统,在50个服务器上使用相同的数据集(键值对).此数据集的更新次数约为每小时1000次,必须在这50台服务器之间进行复制.我们有一个主系统接收这些更新,并负责将这些更新传播到其他服务器.目前,我们每小时以文件的形式将整个数据集(而不是增量更新)同步到所有服务器.然后将该数据加载到不可变的Koloboke映射中.每个服务器每秒处理大约25000个请求,每个请求对此映射执行30次查找.在这些服务器上接收的请求的平均响应延迟最大约为3毫秒,因此内存中的koloboke映射可以很好地维持这个响应时间.
但是,我们当前在服务器之间同步此数据的系统会导致问题:
1)大多数情况下,这些关键数据的同步在其中一台服务器上失败,导致收入损失
2)由于这些数据存储在内存中,因此它不是持久性的,我们需要在每次服务器重新启动时或每次每小时更新时重新加载这些数据,这会影响应用程序的启动时间.
为了提高效率,我在Koloboke库中探索了Redis,Chronicle Maps和Mutable地图.但是我遇到了所有这些问题的限制:
Redis:Redis支持复制和持久性.但是,在使用其基准测试实用程序时,我发现它可以支持的查找次数仅略高于我们的平均用例(0.8-1.1百万个请求,而不是75万,这是我们每秒的查找次数).此外,通过网络调用redis会损害我们3ms的平均响应时间.
Chronicle Maps:在进一步探索这个问题时,我发现Chronicle Maps支持复制,持久性并且每秒可以服务多达3000万个请求.起初看起来它似乎是一个不错的选择,但后来我发现它们不适用于多图,我们在应用程序中生成它们.此外,它们将数据存储在堆外,因此数据反序列化的成本会导致性能损失.
Koloboke:它的性能很好,可以满足我们的使用需求,但不支持复制和持久性.
我找不到任何支持我们所有用例的东西.我正在寻找这个社区的建议,这些建议可以帮助我们有效地构建这个系统,而不会对性能产生任何严重影 任何有关这方面的帮助将非常感谢!谢谢!