bigint 对于事件日志表来说足够大吗？
现在我知道bigint是2^64； 也就是说，比已知宇宙中的原子还要多。 我不应该担心，因为我的人类大脑根本无法应对这个数字的巨大。
然而，假设我记录了系统中每个类别、产品和订单的每一次更改，从发布到结束。 在担心主键值用完之前，我是否应该先关心表写入的性能？ 我应该将不同优先级的事件记录到不同的事件表中吗？ 在用完 bigint 之前，我会用完硬盘上的原子吗？ 在开始归档/清除事件日志表之前，我应该让事件日志表有多大？
Now I know that bigint is 2^64; that is, more atoms than there are in the known universe. I shouldn't be worried, as my mere human brain simply can't get around the enormity of that number.
However, let's say that I record every change to every category, product and order in my system, from launch until the end of time. Should I be concerned about the performance of table writes before I worry about running out of primary key values? Should I record events of different priorities to different event tables? Will I run out of atoms on a hard drive before I run out of bigints? How big should I let an event log table get before I start archiving / clearing it out?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
即使您的每个条目只有 1 个字节，2^64 个条目也会在您的硬盘上占用大约 18000000 TB，所以我想您不必担心这一点。
Even if every of your entries only had 1 byte, 2^64 entries would occupy around 18000000 TB on your hard drive, so I guess you shouldn't worry about this.
如果您的应用程序每百万分之一秒向表中添加一条记录，那么在用完键之前，它将运行超过五十万年。
If your application added a record to the table once every millionth of a second, it would run for over five hundred thousand years before it ran out of keys.
“在开始归档/清除事件日志表之前，我应该让事件日志表达到多大？”
切勿清除事件日志——该信息具有重要价值。
然而，当某些经理坚持认为归档是必要的时，您可以显示存储成本与时间成本的比较，以（a）思考它，（b）获得第二和第三意见，然后（c）写一个归档日志记录的过程。
存储成本正在直线下降。 除了清除日志记录之外，您的时间最好花在任何事情上。
底线：你有权停止绞尽脑汁。 都很好。 你没有犯根本性的错误。
"How big should I let an event log table get before I start archiving / clearing it out?"
Never clear the event logs -- the information has significant value.
However, when some manager insists that an archive is necessary, you can show the cost of storage vs. the cost of your time to (a) think about it, (b) get second and third opinions, and then (c) write a procedure to archive log records.
The cost of storage is plummeting. Your time is better spent on ANYTHING other than purging log records.
Bottom line: you have permission to stop wringing your hands. It's all good. You're not making a fundamental mistake.
您不太可能用完主键值。 但是，您可能需要考虑如何访问日志表以检索数据。 使用它来通知您何时应该归档或清理数据。 如果频繁读取日志数据，请考虑添加索引以提高读取性能，但请记住，需要为添加的每条记录维护索引。
It is highly unlikely that you will ever run out of primary key values. However you may need to give consideration to how you want to access the log table to retrieve data. Use this to inform when you should be archiving or cleaning the data. If the log data is read frequently think about addding indexes to improve read performance but keep in mind that indexes need to be maintained for every record added.
我们处理此问题的方法是提供日志归档功能，该功能按年份将日志表分离到单独的数据库中，从而允许我们重置 LogEvent 表上的身份种子。
我们还有不同的日志表，尽管只有两个主要的。
The way we handle this is by providing a log archiving functionality, that separates out the log table into separate databases by year, allowing us to reset the identity seed on our LogEvent table.
We also have different log tables, though only two main ones.