要做一个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? 完全没有经验，希望有经验的人能赐教一下。
你从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.
你从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
比如 点击一下， 对应的 counter 加1 ， video 结束， 看了多久， 记录对应的时间。 this is time series db. 当然缺点也很明显， 要事先定义好各种 counter, 因为不记录原始数据， 只是 各种metrics. gokgs 发表于 2023-05-18 23:27
即使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是什么，你能具体说说遇到了什么问题吗（这样我可以避免同样的问题）？
即使你是普通用户，也比我知道的要多， 所以感谢你的建议。 你说“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 汇报，痛不欲生，噩梦做好几年。
谢谢你这么详尽的解释。 对于报表，数据分析，我倾向于利用已有的现成的系统，只是把数据upload上去，可以随便怎么产生用户想要的图表。我刚看了看， kibana/elasticsearch 觉得功能挺强。现在的关键是要把log的结构搞清楚，有了数据后，ingest到现成的工具中，对我们开发而言，就少了一份工作。 所以现在关键是log的结构怎么定。如果log写到Dynamo DB，有些app数据还在RDBMS中，那需要pull data out from both and join them. DynamoDB is not for joins. So I am wondering if it's better to write the log into a log file, then batch load it to a RDBMS using the approach that you mentioned. postgres can store Json data. So some unstructured data can be stored as Json. Since we are not writing every log data immediately to the RDBMS, we can avoid the connection or write performance issue. Another approach is at the time of logging the user operation, write the needed app data to the log file, this way, the log data may have all the data it needs so there is no need to join with the app data DB. 也许我的想法不对， 不过写出来也帮助我理清头绪。 我对AWS很不了解，感谢你提供的pointers， 至少我可以查查这方面的资料。我试过serverless， 发现没做什么，已经被charge了，不知道实际中会不会太贵了，还有dynamoDB。
谢谢你这么详尽的解释。 对于报表，数据分析，我倾向于利用已有的现成的系统，只是把数据upload上去，可以随便怎么产生用户想要的图表。我刚看了看， kibana/elasticsearch 觉得功能挺强。现在的关键是要把log的结构搞清楚，有了数据后，ingest到现成的工具中，对我们开发而言，就少了一份工作。 所以现在关键是log的结构怎么定。如果log写到Dynamo DB，有些app数据还在RDBMS中，那需要pull data out from both and join them. DynamoDB is not for joins. So I am wondering if it''''s better to write the log into a log file, then batch load it to a RDBMS using the approach that you mentioned. postgres can store Json data. So some unstructured data can be stored as Json. Since we are not writing every log data immediately to the RDBMS, we can avoid the connection or write performance issue. Another approach is at the time of logging the user operation, write the needed app data to the log file, this way, the log data may have all the data it needs so there is no need to join with the app data DB. 也许我的想法不对， 不过写出来也帮助我理清头绪。 我对AWS很不了解，感谢你提供的pointers， 至少我可以查查这方面的资料。我试过serverless， 发现没做什么，已经被charge了，不知道实际中会不会太贵了，还有dynamoDB。 yongyuan 发表于 2023-05-20 18:37
这个讲 ELK/logstash/kibana, 我以前用过一点， 感觉讲的挺对的， 5 min read. 我也不建议用， 太难用。 https://www.chaossearch.io/blog/elk-stack-pros-and-cons hadoop/hive 也差不多， 大公司用的很多， 也是 maintainace 巨高， that''''s why snowflake/databrick become more and more popular.
5 minute read for snowflake vs databrick, https://geekflare.com/databricks-vs-snowflake/ 你可以 search 几个 youtube video, 应该还是很好用的， 当然不是 free 的。
Amazon CloudWatch Real User Monitoring (RUM) adds the ability for customers to define custom metrics that will be sent to CloudWatch Metrics. Customers can define metrics based on data in customer-defined events (Custom Events), pre-defined RUM events and customer- defined metadata attributes (Custom Attributes). RUM 是 monitoring 的， 人家楼主是要 run 报表， 数据分析。
Amazon CloudWatch Real User Monitoring (RUM) adds the ability for customers to define custom metrics that will be sent to CloudWatch Metrics. Customers can define metrics based on data in customer-defined events (Custom Events), pre-defined RUM events and customer- defined metadata attributes (Custom Attributes). RUM 是 monitoring 的， 人家楼主是要 run 报表， 数据分析。 gokgs 发表于 2023-05-20 19:37
In addition, which is better, MySQL or PostgreSQL for the relational DB?
完全没有经验，希望有经验的人能赐教一下。
再说你已经在AWS上了不是有cloudwatch 吗.
cloudwatch 能customize what to log吗？
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.
无论日志数据写道文件，还是数据库里面，都可以被splunk , datadog这些工具把日志汇总再分析。
写到关系数据库的好处是BI的工具多，容易用SQL查询分析，简单方便。如果你用Java，Log4j可以直接同时写到log文件和数据库里面。重要操作写数据库，日常记录写日志文件。如果你每天的日志文件记录数量不到百万级， 写数据库的性能影响不大。数据库有一个限制就是数据库的connection必须建立才能写入。有些系统日志生成的时候数据库连接还没有建立，或者数据库的连接断了也不能写入。dynamoDB通常没有这个问题。可以高并发高可用。cloudwatch尽量不要用来永久保存重要的数据。所有的日志文件和cloudwatch是一样的，可以用来检查某次发生的事件，或者分析某段时间的信息。重要数据如果没有转移到专门的数据库中保存，日志文件都可能丢失或者被无意删掉，不适合作为长期数据保存和分享使用的标准。
chatgpt也是你的好朋友
Google 只能查出一片片零散的信息，并不能和有过这些经验的人相比。
很有用的信息！
splunk 需要花钱的吧，如果他们没有这个budget就没法用splunk.
Good point. 那就ELK吧，都是open sourced. https://logz.io/learn/complete-guide-elk-stack/amp/
很久之前用SOLR 的时候还submit 过PR to Lucene. 现在应该还在ES的build 里。
然后用batch processing 把这些file读如到db里面 用什么db其实没那么重要 重点是读写分离
谢谢！他们现在用的是 elasticsearch/kibana ，但是不知道为什么建议我们用NoSQL。 因为对这几个都不了解，所以还在研究
你说的关于数据库的connection的问题有道理，因为如果考虑到用户的数量和记录他们的操作数据量，每次写都要连接DB，这真是个问题。对dynamoDB的担心是不知道好不好用它分析数据。我再研究一下前面一个层主发的信息。 谢谢你！
mysql postgres, 应该直接 pass 掉， 因为根本不 scalable， 除非你家的数据量很小， 稍微中型以上的公司都应该考虑 scalability 的问题。
nosql 可以是一个选项， hive 其实就是 nosql 的一种， 不过这些用起来都巨麻烦， 好多公司都有专门的 team 管这个。
有专门的 data warehouse 公司， 专门做这些数据分析的， 不过要把你的 data dump 到他们 云里面。
最简单最有效的办法其实是只 加 各种各样的 counter, counter 其实也有专门的数据库， 不过站的空间应该小多了， 也有专门配套的一些工具。
还没想到这一点--先写在文件里，然后写到DB。我看到一篇文章，说写到dynamo DB里然后在写到relationalDB for query. 谢谢提醒"读写分离"！是需要考虑
log query 用 ELK 显然不适合。
谢谢你提供的这么多的pointers, 我研究一下！非常 感谢！
你说的对，因为对log data 的分析，不需要实时，所以可以先把data store下来，然后在存到DB里。
ELK 的特点是快， 但是要 build 各种 index， 所以浪费， 根本不适用 log query.
“加各种各样的 counter”是什么意思？好像AWS Aurora MySQL/postgres 说可以automatically scalable based on needs, 不知道是不是好用
你有什么建议吗？我对ELK完全不了解
看了你的post, 想到AWS 有没有类似的service，好像还真有， Amazon OpenSearch Service ，说是derived from Elasticsearch
AWS 把open source 的好多都做了一遍，有的是fork, 有的是包装，有的是same interface but different implementation - EKS, Big Mesh, AMQ, elastic cache, Kinesis, MKS，etc.
我这个不是回前面一个贴找个low cost / free solution 吗。
比如 点击一下， 对应的 counter 加1 ， video 结束， 看了多久， 记录对应的时间。
this is time series db.
当然缺点也很明显， 要事先定义好各种 counter, 因为不记录原始数据， 只是 各种metrics.
反正排除 ELK 就是了。
如果你的数据分析是interactive的，建议研究一下Trino；如果是batch，建议研究一下Spark。一般是把数据以columnar的形式存在aws S3。
如果规模小的话，建议直接用aws EMR，或snowflake。
看她实际的usecase, TS的话用influxdb.
还有人提到EMR/snowflake, 也是看她analytical 的需要。
这个中间一定的有个persisted 的缓存的。否则RDBMS就成了你的瓶颈和SPOF， 启动的时候，offline 的时候, network 慢的时候，其他task competing with resources 的时候， log 都不能及时，atomic 的写进去。本来就不需要实时。
有道理！这样展开说，确实觉得RDBMS不合适了，谢谢
谢谢！现在关键是数据存在哪里以便于以后分析
好的，不是interactive 的，其实就是分析什么是popular的topic, 等等。规模目前不大，公司刚起步，好像现在的log 有10多G
不知道query， 产生图表好不好用。谢谢，我查查。你有用过mongodb， 它有这种功能吗？
谢谢，我查查。
又是一个没听说过的，我研究一下，谢谢
在AWS里面解决读写不难。如果关系数据库的连接是瓶颈，日志先写到文件里面的话，建立一个SQS的pipeline就可以了，SQS调用Lambda再把数据汇总到数据库。如果日志记录多，Lambda里面数据库用连接池可以保证繁忙的时候总是可以重用已有的连接，而且可以自动扩展Lambda的数量。Lambda写到Dynamodb没有connection的问题。这个方案实现起来很容易的，而且能满足你们的需求。如果你们没有用Splunk去管理其它系统的日志，个人觉得没有必要买Splunk。很多公司花很多钱买BI，data warehouse工具，真正用到的功能就是report和query，还不到这些工具的20%。
楼主有个最关键的问题要弄清楚，你的日志文件数据量存储是在百万级，还是要在亿万级，并发的数量是多少，这直接影响你的方案选择和成本。
这个顶一下，挺完整的一个方案。当然there is no free lunch, 都是得付钱，调throttling 的。
非常感谢你的方案！就是说，你建议，如果用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的功能。
“很多公司花很多钱买BI，data warehouse工具，真正用到的功能就是report和query，还不到这些工具的20%。”
那你的意思是自己实现， report 的功能？
现在的log数据大概有 几个GB， 客户还在发展中，现在规模小，我猜concurrent access 最多现在能有上百？（我也不知道）。根据你的经验，你觉得上面你说的方案可行不？
即使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.
即使你是普通用户，也比我知道的要多， 所以感谢你的建议。 你说“I was involved in a COE once for one of those mentioned services in front of CB. Never wanna do that again.” 我不大懂你说的 COE 和CB是什么，你能具体说说遇到了什么问题吗（这样我可以避免同样的问题）？
这个和你没啥关系哈哈哈。COE 是亚麻内部的incident review, CB 是Charlie Bell, 以前AWS 的管Ops 的最大头。我是说那些HA services 也一样有outage， 你一定要design your own services around that - 出了事负责的SDM要向Charlie 汇报，痛不欲生，噩梦做好几年。
原来如此！ 哈哈！看来你还是内部人员啊！那一定是噩梦！看来这些service不可能100%reliable
你们需要的report功能，问问你们开发人员如果自己做要多少成本，然后比较一下买其它产品是多少成本。通常的报表对技术人员并不需要花很多时间。如果用到的功能都差不多，钱不是大问题的时候，自己做的产品就像自己家的娃，完全可以按照自己的系统设计到达最优化， 可以遇见的风险小；别人的产品就像别人家的娃，产品不支持自己平台的部分或者技术不公开的部分需要特别费力去解决问题，存在各种风险。别人家的娃总是不如自己家的娃好用。长期的技术产品都尽量选用自己的产权。
如果你们不需要实时处理高并发，用SQS加几秒延迟可以有效平滑sudden spikes in traffic，提高系统的稳定性。SQS每秒处理几百个消息应该很轻松。如果你们的App准备运行在Serverless，日志应该是存在S3，Lambda读写都没问题。如果App运行在EC2或者容器里面，要拷到S3里面才能用Lambda。直接EC2到DynamoDB也可以，不要每条记录都单独一个transaction，最好能batch load模式。SQS/Lambda也是一个batch load模式，日志从EC2 batch copy到S3，Lambda batch load进入DynamoDB。细节不一样的地方是，用SQS pipeline来实现这个功能，EC2 batch copy日志到S3很简单，SQS自动扩展系统容量很容易，Lambda的功能也容易被其它系统共享。
谢谢你这么详尽的解释。 对于报表，数据分析，我倾向于利用已有的现成的系统，只是把数据upload上去，可以随便怎么产生用户想要的图表。我刚看了看， kibana/elasticsearch 觉得功能挺强。现在的关键是要把log的结构搞清楚，有了数据后，ingest到现成的工具中，对我们开发而言，就少了一份工作。
所以现在关键是log的结构怎么定。如果log写到Dynamo DB，有些app数据还在RDBMS中，那需要pull data out from both and join them. DynamoDB is not for joins. So I am wondering if it's better to write the log into a log file, then batch load it to a RDBMS using the approach that you mentioned. postgres can store Json data. So some unstructured data can be stored as Json. Since we are not writing every log data immediately to the RDBMS, we can avoid the connection or write performance issue.
Another approach is at the time of logging the user operation, write the needed app data to the log file, this way, the log data may have all the data it needs so there is no need to join with the app data DB.
也许我的想法不对， 不过写出来也帮助我理清头绪。
我对AWS很不了解，感谢你提供的pointers， 至少我可以查查这方面的资料。我试过serverless， 发现没做什么，已经被charge了，不知道实际中会不会太贵了，还有dynamoDB。
我得研究一下snowflake。现在我感觉真的是需要先把log结构定好，然后把它dump到什么工具中，产生图表。snowflake是干这个的吗
你研究一下， 还有 databrick, 比较一下， 他们都是做这个的， 我感觉 kibana/elasticsearch 不应该是干这个的，尽管也有 search 和图标的功能， 我用过， 不是很熟， 一会儿我也 google 一下。
这个讲 ELK/logstash/kibana, 我以前用过一点， 感觉讲的挺对的， 5 min read. 我也不建议用， 太难用。
https://www.chaossearch.io/blog/elk-stack-pros-and-cons
hadoop/hive 也差不多， 大公司用的很多， 也是 maintainace 巨高， that''''s why snowflake/databrick become more and more popular.
5 minute read for snowflake vs databrick, https://geekflare.com/databricks-vs-snowflake/ 你可以 search 几个 youtube video, 应该还是很好用的， 当然不是 free 的。
log 结构就是 json 就好了， timestamp, message, 两个必须的， 别的那个重要就加那个， 看你的应用， 也可以有 nested objects, 当然尽量 flat, query 的时候容易。
Amazon CloudWatch Real User Monitoring (RUM) adds the ability for customers to define custom metrics that will be sent to CloudWatch Metrics. Customers can define metrics based on data in customer-defined events (Custom Events), pre-defined RUM events and customer- defined metadata attributes (Custom Attributes).
RUM 是 monitoring 的， 人家楼主是要 run 报表， 数据分析。
Cloudwatch metrics 不能用来数据分析？直接Quicksight 连Athena到CW。不需要用到任何数据库。