noSQL DB or relational DB for log data

要做一个project， 需要存储user的每个页面操作，比如点击了什么link， 看了什么video，多长时间，目的是以后分析user log data，做图表。大家有没有这方面的经验可以分享。因为要存储用户的每个操作，所以会有很多write operations，有人建议用NoSQL， 因为structure of data may change， 有人建议postgreSQL,说可以存JSON data, can do complex queries，现在的concern是，如果这个软件的本身数据也存在postgreSQL， 需要pull data from the DB to show to the users, 同时还要大量地write to the log, will the performance suffer? 另外，以后可能要用AWS，看了它有NOSQL DB-- dynamoDB，这个存储user log，可以吗？看到他是key value-based. 那如果要做其他数据查询（比如，search based on non-key field和aggregate data,会不会有问题？if we store the application data in a relational DB, and the log data in dynamoDB, can we still query the DynamoDB, aggregate data, and generate reports, or do we need to pull the data out from the dynamoDB, and later store it in a relational DB for data analysis (e.g. we may need to join the log data with the actual application data to find some information that''s not available in the url--should we just store the extra information in the log so that we don''t have to join with the actual application data)?
In addition, which is better, MySQL or PostgreSQL for the relational DB?
完全没有经验，希望有经验的人能赐教一下。

这个OBS标准操作不是splunk , datadog, Prometheus ， elasticsearch/kibana 吗。用RDBMS 的话I/O多贵啊。用Dynamodb 的话你得自己加ingress, pipeline, aggregation and visualization, reinvent all the wheels.
再说你已经在AWS上了不是有cloudwatch 吗.

这个OBS标准操作不是splunk , datadog, Prometheus ， elasticsearch/kibana 吗。用RDBMS 的话I/O多贵啊。用Dynamodb 的话你得自己加ingress, pipeline, aggregation and visualization, reinvent all the wheels.
再说你已经在AWS上了不是有cloudwatch 吗.
Sleepy3824 发表于 2023-05-18 18:48

cloudwatch 能customize what to log吗？

Google是你的好朋友。。。

你从YouTube 里找点splunk 的video 开始吧。
You can also push customized application logs into cloud watch: https://devopscube.com/how-to-setup-and-push-serverapplication-logs-to-aws-cloudwatch/
Whatever you do, do NOT store your log data in the same RDBMS as your application.

一楼的问题是需要的数据存log文件，RDBMS还是NoSQL。听上去系统和服务里面没有这些日志数据，需要自己写代码来创建。
无论日志数据写道文件，还是数据库里面，都可以被splunk , datadog这些工具把日志汇总再分析。
写到关系数据库的好处是BI的工具多，容易用SQL查询分析，简单方便。如果你用Java，Log4j可以直接同时写到log文件和数据库里面。重要操作写数据库，日常记录写日志文件。如果你每天的日志文件记录数量不到百万级， 写数据库的性能影响不大。数据库有一个限制就是数据库的connection必须建立才能写入。有些系统日志生成的时候数据库连接还没有建立，或者数据库的连接断了也不能写入。dynamoDB通常没有这个问题。可以高并发高可用。cloudwatch尽量不要用来永久保存重要的数据。所有的日志文件和cloudwatch是一样的，可以用来检查某次发生的事件，或者分析某段时间的信息。重要数据如果没有转移到专门的数据库中保存，日志文件都可能丢失或者被无意删掉，不适合作为长期数据保存和分享使用的标准。

Google是你的好朋友。。。
psyentistc 发表于 2023-05-18 19:12

chatgpt也是你的好朋友

Google是你的好朋友。。。
psyentistc 发表于 2023-05-18 19:12

Google 只能查出一片片零散的信息，并不能和有过这些经验的人相比。

回复 5楼Sleepy3824的帖子
很有用的信息！

你从YouTube 里找点splunk 的video 开始吧。
You can also push customized application logs into cloud watch: https://devopscube.com/how-to-setup-and-push-serverapplication-logs-to-aws-cloudwatch/
Whatever you do, do NOT store your log data in the same RDBMS as your application.
Sleepy3824 发表于 2023-05-18 19:20

splunk 需要花钱的吧，如果他们没有这个budget就没法用splunk.

splunk 需要花钱的吧，如果他们没有这个budget就没法用splunk.
darksky01 发表于 2023-05-18 22:00

Good point. 那就ELK吧，都是open sourced. https://logz.io/learn/complete-guide-elk-stack/amp/
很久之前用SOLR 的时候还submit 过PR to Lucene. 现在应该还在ES的build 里。

Read不是real time的 Write不需要用任何database 直接选择一个file storage就行 可以根据schema 把log file 数据读出来就行
然后用batch processing 把这些file读如到db里面 用什么db其实没那么重要 重点是读写分离

回复 2楼Sleepy3824的帖子
谢谢！他们现在用的是 elasticsearch/kibana ，但是不知道为什么建议我们用NoSQL。 因为对这几个都不了解，所以还在研究

一楼的问题是需要的数据存log文件，RDBMS还是NoSQL。听上去系统和服务里面没有这些日志数据，需要自己写代码来创建。
无论日志数据写道文件，还是数据库里面，都可以被splunk , datadog这些工具把日志汇总再分析。
写到关系数据库的好处是BI的工具多，容易用SQL查询分析，简单方便。如果你用Java，Log4j可以直接同时写到log文件和数据库里面。重要操作写数据库，日常记录写日志文件。如果你每天的日志文件记录数量不到百万级， 写数据库的性能影响不大。数据库有一个限制就是数据库的connection必须建立才能写入。有些系统日志生成的时候数据库连接还没有建立，或者数据库的连接断了也不能写入。dynamoDB通常没有这个问题。可以高并发高可用。cloudwatch尽量不要用来永久保存重要的数据。所有的日志文件和cloudwatch是一样的，可以用来检查某次发生的事件，或者分析某段时间的信息。重要数据如果没有转移到专门的数据库中保存，日志文件都可能丢失或者被无意删掉，不适合作为长期数据保存和分享使用的标准。


sea101 发表于 2023-05-18 20:23

你说的关于数据库的connection的问题有道理，因为如果考虑到用户的数量和记录他们的操作数据量，每次写都要连接DB，这真是个问题。对dynamoDB的担心是不知道好不好用它分析数据。我再研究一下前面一个层主发的信息。 谢谢你！

一般稍微大一点的公司都有这种 log collection system. 你只管 log, 然后就可以查， 好像最笨的是 hive. 然后run query, 慢死人。
mysql postgres, 应该直接 pass 掉， 因为根本不 scalable， 除非你家的数据量很小， 稍微中型以上的公司都应该考虑 scalability 的问题。
nosql 可以是一个选项， hive 其实就是 nosql 的一种， 不过这些用起来都巨麻烦， 好多公司都有专门的 team 管这个。
有专门的 data warehouse 公司， 专门做这些数据分析的， 不过要把你的 data dump 到他们 云里面。
最简单最有效的办法其实是只 加 各种各样的 counter, counter 其实也有专门的数据库， 不过站的空间应该小多了， 也有专门配套的一些工具。

Read不是real time的 Write不需要用任何database 直接选择一个file storage就行 可以根据schema 把log file 数据读出来就行
然后用batch processing 把这些file读如到db里面 用什么db其实没那么重要 重点是读写分离
dalianyin 发表于 2023-05-18 22:20

还没想到这一点--先写在文件里，然后写到DB。我看到一篇文章，说写到dynamo DB里然后在写到relationalDB for query. 谢谢提醒"读写分离"！是需要考虑

Good point. 那就ELK吧，都是open sourced. https://logz.io/learn/complete-guide-elk-stack/amp/
很久之前用SOLR 的时候还submit 过PR to Lucene. 现在应该还在ES的build 里。
Sleepy3824 发表于 2023-05-18 22:07

log query 用 ELK 显然不适合。

Good point. 那就ELK吧，都是open sourced. https://logz.io/learn/complete-guide-elk-stack/amp/
很久之前用SOLR 的时候还submit 过PR to Lucene. 现在应该还在ES的build 里。
Sleepy3824 发表于 2023-05-18 22:07

谢谢你提供的这么多的pointers, 我研究一下！非常 感谢！

Read不是real time的 Write不需要用任何database 直接选择一个file storage就行 可以根据schema 把log file 数据读出来就行
然后用batch processing 把这些file读如到db里面 用什么db其实没那么重要 重点是读写分离
dalianyin 发表于 2023-05-18 22:20

你说的对，因为对log data 的分析，不需要实时，所以可以先把data store下来，然后在存到DB里。

你说的对，因为对log data 的分析，不需要实时，所以可以先把data store下来，然后在存到DB里。
yongyuan 发表于 2023-05-18 23:01

ELK 的特点是快， 但是要 build 各种 index， 所以浪费， 根本不适用 log query.

一般稍微大一点的公司都有这种 log collection system. 你只管 log, 然后就可以查， 好像最笨的是 hive. 然后run query, 慢死人。
mysql postgres, 应该直接 pass 掉， 因为根本不 scalable， 除非你家的数据量很小， 稍微中型以上的公司都应该考虑 scalability 的问题。
nosql 可以是一个选项， hive 其实就是 nosql 的一种， 不过这些用起来都巨麻烦， 好多公司都有专门的 team 管这个。
有专门的 data warehouse 公司， 专门做这些数据分析的， 不过要把你的 data dump 到他们 云里面。
最简单最有效的办法其实是只 加 各种各样的 counter, counter 其实也有专门的数据库， 不过站的空间应该小多了， 也有专门配套的一些工具。


gokgs 发表于 2023-05-18 22:56

“加各种各样的 counter”是什么意思？好像AWS Aurora MySQL/postgres 说可以automatically scalable based on needs, 不知道是不是好用

ELK 的特点是快， 但是要 build 各种 index， 所以浪费， 根本不适用 log query.
gokgs 发表于 2023-05-18 23:04

你有什么建议吗？我对ELK完全不了解

Good point. 那就ELK吧，都是open sourced. https://logz.io/learn/complete-guide-elk-stack/amp/
很久之前用SOLR 的时候还submit 过PR to Lucene. 现在应该还在ES的build 里。
Sleepy3824 发表于 2023-05-18 22:07

看了你的post, 想到AWS 有没有类似的service，好像还真有， Amazon OpenSearch Service ，说是derived from Elasticsearch

听着像实现类似google analytics的data collection。 可以用JS page tag 插入到每个页面。每当用户访问一个页面， JS就收集用户数据，并发送到data collection server，分类处理。 在服务端调用SQL，就可以看到用户access网站的各类数据。

看了你的post, 想到AWS 有没有类似的service，好像还真有， Amazon OpenSearch Service ，说是derived from Elasticsearch
yongyuan 发表于 2023-05-18 23:17

AWS 把open source 的好多都做了一遍，有的是fork, 有的是包装，有的是same interface but different implementation - EKS, Big Mesh, AMQ, elastic cache, Kinesis, MKS，etc.

log query 用 ELK 显然不适合。
gokgs 发表于 2023-05-18 22:59

我这个不是回前面一个贴找个low cost / free solution 吗。

“加各种各样的 counter”是什么意思？好像AWS Aurora MySQL/postgres 说可以automatically scalable based on needs, 不知道是不是好用
yongyuan 发表于 2023-05-18 23:06

比如 点击一下， 对应的 counter 加1 ， video 结束， 看了多久， 记录对应的时间。
this is time series db.
当然缺点也很明显， 要事先定义好各种 counter, 因为不记录原始数据， 只是 各种metrics.

你有什么建议吗？我对ELK完全不了解
yongyuan 发表于 2023-05-18 23:07

反正排除 ELK 就是了。

你的目的是数据分析，也就是OLAP。你说的RDBMS是针对OLTP的，不太适合OLAP。
如果你的数据分析是interactive的，建议研究一下Trino；如果是batch，建议研究一下Spark。一般是把数据以columnar的形式存在aws S3。
如果规模小的话，建议直接用aws EMR，或snowflake。

比如 点击一下， 对应的 counter 加1 ， video 结束， 看了多久， 记录对应的时间。
this is time series db.
当然缺点也很明显， 要事先定义好各种 counter, 因为不记录原始数据， 只是 各种metrics.
gokgs 发表于 2023-05-18 23:27

看她实际的usecase, TS的话用influxdb.
还有人提到EMR/snowflake, 也是看她analytical 的需要。

还没想到这一点--先写在文件里，然后写到DB。我看到一篇文章，说写到dynamo DB里然后在写到relationalDB for query. 谢谢提醒"读写分离"！是需要考虑
yongyuan 发表于 2023-05-18 22:56

这个中间一定的有个persisted 的缓存的。否则RDBMS就成了你的瓶颈和SPOF， 启动的时候，offline 的时候, network 慢的时候，其他task competing with resources 的时候， log 都不能及时，atomic 的写进去。本来就不需要实时。

这个中间一定的有个persisted 的缓存的。否则RDBMS就成了你的瓶颈和SPOF， 启动的时候，offline 的时候, network 慢的时候，其他task competing with resources 的时候， log 都不能及时，atomic 的写进去。本来就不需要实时。
Sleepy3824 发表于 2023-05-18 23:41

有道理！这样展开说，确实觉得RDBMS不合适了，谢谢

听着像实现类似google analytics的data collection。 可以用JS page tag 插入到每个页面。每当用户访问一个页面， JS就收集用户数据，并发送到data collection server，分类处理。 在服务端调用SQL，就可以看到用户access网站的各类数据。

gvcc 发表于 2023-05-18 23:19

谢谢！现在关键是数据存在哪里以便于以后分析

少研究一个，好！

你的目的是数据分析，也就是OLAP。你说的RDBMS是针对OLTP的，不太适合OLAP。
如果你的数据分析是interactive的，建议研究一下Trino；如果是batch，建议研究一下Spark。一般是把数据以columnar的形式存在aws S3。
如果规模小的话，建议直接用aws EMR，或snowflake。
bochs 发表于 2023-05-18 23:32

好的，不是interactive 的，其实就是分析什么是popular的topic, 等等。规模目前不大，公司刚起步，好像现在的log 有10多G

你的需求和log 没啥关系啊，明明就是非结构化数据，这么多人没人推荐mongodb? 免费的，开源的，收费的，丰俭由人，难道不香吗？

你这个要求是做analytics ， 应该看clickhouse 或者Cassandra 那种column store。

我的建议是metric 比如influxdb

你的需求和log 没啥关系啊，明明就是非结构化数据，这么多人没人推荐mongodb? 免费的，开源的，收费的，丰俭由人，难道不香吗？
果子果子 发表于 2023-05-19 00:35

不知道query， 产生图表好不好用。谢谢，我查查。你有用过mongodb， 它有这种功能吗？

Mark

你这个要求是做analytics ， 应该看clickhouse 或者Cassandra 那种column store。
ted.hanks 发表于 2023-05-19 02:09

谢谢，我查查。

我的建议是metric 比如influxdb
mt.everest 发表于 2023-05-19 07:05

又是一个没听说过的，我研究一下，谢谢

这个中间一定的有个persisted 的缓存的。否则RDBMS就成了你的瓶颈和SPOF， 启动的时候，offline 的时候, network 慢的时候，其他task competing with resources 的时候， log 都不能及时，atomic 的写进去。本来就不需要实时。
Sleepy3824 发表于 2023-05-18 23:41

在AWS里面解决读写不难。如果关系数据库的连接是瓶颈，日志先写到文件里面的话，建立一个SQS的pipeline就可以了，SQS调用Lambda再把数据汇总到数据库。如果日志记录多，Lambda里面数据库用连接池可以保证繁忙的时候总是可以重用已有的连接，而且可以自动扩展Lambda的数量。Lambda写到Dynamodb没有connection的问题。这个方案实现起来很容易的，而且能满足你们的需求。如果你们没有用Splunk去管理其它系统的日志，个人觉得没有必要买Splunk。很多公司花很多钱买BI，data warehouse工具，真正用到的功能就是report和query，还不到这些工具的20%。
楼主有个最关键的问题要弄清楚，你的日志文件数据量存储是在百万级，还是要在亿万级，并发的数量是多少，这直接影响你的方案选择和成本。

不是有pendo heap这种吗。是太贵了？

在AWS里面解决读写不难。如果关系数据库的连接是瓶颈，日志先写到文件里面的话，建立一个SQS的pipeline就可以了，SQS调用Lambda再把数据汇总到数据库。如果日志记录多，Lambda里面数据库用连接池可以保证繁忙的时候总是可以重用已有的连接，而且可以自动扩展Lambda的数量。Lambda写到Dynamodb没有connection的问题。这个方案实现起来很容易的，而且能满足你们的需求。如果你们没有用Splunk去管理其它系统的日志，个人觉得没有必要买Splunk。很多公司花很多钱买BI，data warehouse工具，真正用到的功能就是report和query，还不到这些工具的20%。
楼主有个最关键的问题要弄清楚，你的日志文件数据量存储是在百万级，还是要在亿万级，并发的数量是多少，这直接影响你的方案选择和成本。

sea101 发表于 2023-05-19 09:40

这个顶一下，挺完整的一个方案。当然there is no free lunch, 都是得付钱，调throttling 的。

学习了 mark

在AWS里面解决读写不难。如果关系数据库的连接是瓶颈，日志先写到文件里面的话，建立一个SQS的pipeline就可以了，SQS调用Lambda再把数据汇总到数据库。如果日志记录多，Lambda里面数据库用连接池可以保证繁忙的时候总是可以重用已有的连接，而且可以自动扩展Lambda的数量。Lambda写到Dynamodb没有connection的问题。这个方案实现起来很容易的，而且能满足你们的需求。如果你们没有用Splunk去管理其它系统的日志，个人觉得没有必要买Splunk。很多公司花很多钱买BI，data warehouse工具，真正用到的功能就是report和query，还不到这些工具的20%。
楼主有个最关键的问题要弄清楚，你的日志文件数据量存储是在百万级，还是要在亿万级，并发的数量是多少，这直接影响你的方案选择和成本。

sea101 发表于 2023-05-19 09:40

非常感谢你的方案！就是说，你建议，如果用RDMS的话，可以先把log写在文件里， 然后用SQS send to Lambda, Lambda 可以写到RDBMS。 那如果用Dynamo DB，是不是可以直接写到Dynamodb， 而不需要先写在文件里。前面有个层主说Dynamodb费用高，是不是先写在文件里， 然后用SQS send to Lambda, Lambda 可以写到Dynamodb 更好些？ AWS对我来说也是新的东西，非常不熟悉。
除了存储log data， 另外一个很重要的feature是能提供图表，分析数据。我看了一下前面 Sleepy3824说的 elasticsearch/kibana, 感觉可能能应对他们要求的数据分析，这样就不用 reinvent the wheels. 在软件里开发数据分析，图表功能， 你觉得这样可行吗？
@Sleepy3824， 你觉得这样可行吗？不知道AWS 的 opensearch 有没有kibana的功能。

在AWS里面解决读写不难。如果关系数据库的连接是瓶颈，日志先写到文件里面的话，建立一个SQS的pipeline就可以了，SQS调用Lambda再把数据汇总到数据库。如果日志记录多，Lambda里面数据库用连接池可以保证繁忙的时候总是可以重用已有的连接，而且可以自动扩展Lambda的数量。Lambda写到Dynamodb没有connection的问题。这个方案实现起来很容易的，而且能满足你们的需求。如果你们没有用Splunk去管理其它系统的日志，个人觉得没有必要买Splunk。很多公司花很多钱买BI，data warehouse工具，真正用到的功能就是report和query，还不到这些工具的20%。
楼主有个最关键的问题要弄清楚，你的日志文件数据量存储是在百万级，还是要在亿万级，并发的数量是多少，这直接影响你的方案选择和成本。

sea101 发表于 2023-05-19 09:40

“很多公司花很多钱买BI，data warehouse工具，真正用到的功能就是report和query，还不到这些工具的20%。”
那你的意思是自己实现， report 的功能？
现在的log数据大概有 几个GB， 客户还在发展中，现在规模小，我猜concurrent access 最多现在能有上百？（我也不知道）。根据你的经验，你觉得上面你说的方案可行不？

非常感谢你的方案！就是说，你建议，如果用RDMS的话，可以先把log写在文件里， 然后用SQS send to Lambda, Lambda 可以写到RDBMS。 那如果用Dynamo DB，是不是可以直接写到Dynamodb， 而不需要先写在文件里。前面有个层主说Dynamodb费用高，是不是先写在文件里， 然后用SQS send to Lambda, Lambda 可以写到Dynamodb 更好些？ AWS对我来说也是新的东西，非常不熟悉。
除了存储log data， 另外一个很重要的feature是能提供图表，分析数据。我看了一下前面 Sleepy3824说的 elasticsearch/kibana, 感觉可能能应对他们要求的数据分析，这样就不用 reinvent the wheels. 在软件里开发数据分析，图表功能， 你觉得这样可行吗？
@Sleepy3824， 你觉得这样可行吗？不知道AWS 的 opensearch 有没有kibana的功能。
yongyuan 发表于 2023-05-19 13:37

即使Dynamodb is supposed to be HA, 你也有network 连不上的时候，Dynamodb 可能throttle/back pressure，也有SEV1不在线的时候。所以你不能完全depend on实时的write (PutItem), 一般得有local 的queue/cache on disk.
另一方面你用的AWS service 越多当然费用越高。Unfortunately I was involved in a COE once for one of those mentioned services in front of CB. Never wanna do that again.
话说回来，以你现在的scale, 放在哪里都装得下 -：）sea101 看来对OBS end to end 更熟悉, 我更是个普通user.

即使Dynamodb is supposed to be HA, 你也有network 连不上的时候，Dynamodb 可能throttle/back pressure，也有SEV1不在线的时候。所以你不能完全depend on实时的write (PutItem), 一般得有local 的queue/cache on disk.
另一方面你用的AWS service 越多当然费用越高。Unfortunately I was involved in a COE once for one of those mentioned services in front of CB. Never wanna do that again.
话说回来，以你现在的scale, 放在哪里都装得下 -：）sea101 看来对OBS end to end 更熟悉, 我更是个普通user.


Sleepy3824 发表于 2023-05-19 14:00

即使你是普通用户，也比我知道的要多， 所以感谢你的建议。 你说“I was involved in a COE once for one of those mentioned services in front of CB. Never wanna do that again.” 我不大懂你说的 COE 和CB是什么，你能具体说说遇到了什么问题吗（这样我可以避免同样的问题）？

大数据 data warehouse -> data lake -> lakehourse . DataBricks （原Apache Spark）， 就是一数据大杂烩， 可以看看。 分析工具就五花八门了， Neo4j, Elastic ELK，Solr等等都在Could上跑。

即使你是普通用户，也比我知道的要多， 所以感谢你的建议。 你说“I was involved in a COE once for one of those mentioned services in front of CB. Never wanna do that again.” 我不大懂你说的 COE 和CB是什么，你能具体说说遇到了什么问题吗（这样我可以避免同样的问题）？
yongyuan 发表于 2023-05-19 17:08

这个和你没啥关系哈哈哈。COE 是亚麻内部的incident review, CB 是Charlie Bell, 以前AWS 的管Ops 的最大头。我是说那些HA services 也一样有outage， 你一定要design your own services around that - 出了事负责的SDM要向Charlie 汇报，痛不欲生，噩梦做好几年。