赞助商

postgresql hstore key / value vs传统的SQL性能

发布时间:2019-07-11 发布网站:脚本之家
脚本之家收集整理的这篇文章主要介绍了postgresql hstore key / value vs传统的SQL性能脚本之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我需要开发一个键/值后端,如下所示:
Table T1 id-PK,Key - string,Value - string
INSERT into T1('String1','Value1')
INSERT INTO T1('String1','Value2')

Table T2 id-PK2,id2->external key to id
some other data in T2,which references data in T1 (like users which have those K/V etc)

我听说过带GIN / GIST的PostgreSQL hstore.什么是更好的(性能方面)?
使用SQL连接和具有单独列(键/值)的传统方式执行此操作?
PostgreSQL hstore在这种情况下表现更好吗?

数据的格式应该是任何键=>任何值.
我也想做文字匹配,例如部分搜索(在SQL中使用LIKE%或使用等效的hstore).
我计划在其中包含大约1M-2M的条目,并且可能在某个时刻进行扩展.

您有什么推荐的吗 ?使用持久性的SQL传统方式/ PostgreSQL hstore或任何其他分布式键/值存储?

如果它有帮助,我的服务器是一个具有1-2GB RAM的VPS,所以不是一个非常好的硬件.我还想在此基础上设置一个缓存层,但我认为它使问题复杂化.我只想要2M条目的良好表现.更新将经常进行,但更频繁地进行搜索.

谢谢.

解决方法

您的问题不明确,因为您不清楚自己的目标.

这里的关键是索引(双关语) – 如果你处理大量的密钥,你希望能够用最少的查找来检索它们而不需要提取不相关的数据.

简短的回答是你可能不想使用hstore,但让我们来看看更多细节……

>每个id都有很多键/值对(数百个)吗?不要使用hstore.
>您的任何值是否包含大块文本(4kb)?不要使用hstore.
>您是否希望能够通过通配符表达式按键搜索?不要使用hstore.
>您想进行复杂的连接/聚合/报告吗?不要使用hstore.
>您会更新单个键的值吗?不要使用hstore.
> ID下具有相同名称的多个键?不能使用hstore.

那么什么是hstore的用途?好吧,一个好的方案是,如果你想为外部应用程序保存键/值对,你知道你总是想要检索所有键/值,并且总是将数据保存为块(即,它永远不会被编辑 – 地点).与此同时,您确实需要一些灵活性来搜索这些数据 – 非常简单 – 而不是将其存储在XML或JSON块中.在这种情况下,由于键/值对的数量很小,因此您可以节省空间,因为您将几个元组压缩到一个hstore中.

将此视为您的表格:

CREATE TABLE kv (
  id /* SOME TYPE */ PRIMARY KEY,key_name TEXT NOT NULL,key_value TEXT,UNIQUE(id,key_name)
);

总结

以上是脚本之家为你收集整理的postgresql hstore key / value vs传统的SQL性能全部内容,希望文章能够帮你解决postgresql hstore key / value vs传统的SQL性能所遇到的程序开发问题。

如果觉得脚本之家网站内容还不错,欢迎将脚本之家网站推荐给程序员好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:76874919,请注明来意。
标签: