美国性罪犯跟踪数据库因为超过二十亿条记录而停运

bulaohu

这个数据库因为超过最大记录数而停止运行，导致美国各大执法机构有12个小时的时间无法监控各种性罪犯。

二十亿条？美国有多少sex offender?。。。



http://www.bbc.co.uk/news/world-us-canada-11491937

Thousands of US sex offenders, prisoners on parole and other convicts were left unmonitored after an electronic tagging system shut down because of data overload.

BI Incorporated, which runs the system, reached its data threshold - more than two billion records - on Tuesday.

This left authorities across 49 states unaware of offenders' movement for about 12 hours.

BI increased its data storage capacity to avoid a repeat of the problem.

Prisons and other corrections agencies were blocked from getting notifications on about 16,000 people, BI Incorporated spokesman Jock Waldo said on Wednesday.

Continue reading the main story
“
Start Quote

In retrospect, we should have been able to catch this”

Jock Waldo
BI Incorporated spokesman
"At 0729 Mountain Time [1429 GMT] on 5 October, BI Incorporated experienced a problem with one of its offender monitoring servers that caused this server's automatic notification system to be temporarily disabled, resulting in delayed notifications to customers. The issue was resolved approximately 12 hours later at 1925 [0229 GMT Wednesday]," BI said in a statement.

Tracking devices continued to record movement and gather information, but corrections agencies could not immediately view the data, BI said.

In Wisconsin, local police and probation agents held about 140 sex offenders at local jails until the GPS tracking system was restored.

The offenders - about 300 in the state, most of them sex offenders - were never aware they were not being tracked, state Department of Corrections spokeswoman Linda Eggert said.

"In retrospect, we should have been able to catch this," Mr Waldo is quoted as saying by the AP news agency.

Tiger_Karen

虎哥啥时候又换头像了

kane2001

二十亿条就挂了？ 莫非把罪犯的照片 扫描文档都存在一个Binary Column里了

chinara

不知道是什么数据库？

bulaohu

原帖由 Tiger_Karen 于 2010-10-9 19:54 发表
虎哥啥时候又换头像了

刚换，没几天

yuba

总换头像会不会无谓地增加记录条数

dalaohu

primary key 用int， 怎么着也用个大一点的呀。

jerryclark

所以和人PK的时候我用long。在不行只能出guid。

[ 本帖最后由 jerryclark 于 2010-10-9 20:35 编辑 ]

bulaohu

原帖由 yuba 于 2010-10-9 20:46 发表
总换头像会不会无谓地增加记录条数

哈哈

大饼

原帖由 dalaohu 于 2010-10-9 21:28 发表
primary key 用int， 怎么着也用个大一点的呀。

俺用的系统里int大部分是16位的

bulaohu

用int有点危险吧。大点的数据库还有用int的吗？

bulaohu

wiki:

Common sizes

Programming language        Approval Type        Platforms        Data type name        Storage in bytes        Range (Signed)        Range (Unsigned)
C ISO/ANSI C99        International Standard        Unix,16/32-bit systems[3]
Windows,16/32/64-bit systems[3]        long†        4
(minimum requirement 4)        −2,147,483,648 to 2,147,483,647
(minimum requirement)        0 to 4,294,967,295
(minimum requirement)
C ISO/ANSI C99        International Standard        Unix,
64-bit systems[3][4]        long†        8
(minimum requirement 4)        −9,223,372,036,854,775,808 to +9,223,372,036,854,775,807        0 to 18,446,744,073,709,551,615
C++ ISO/ANSI        International Standard        Unix, Windows,
16/32-bit system        long†        4 [5]
(minimum requirement 4)        −2,147,483,648 to 2,147,483,647
(minimum requirement)        0 to 4,294,967,295
(minimum requirement)
C++/CLI        International Standard
ECMA-372        Unix, Windows,
16/32-bit systems        long†        4 [6]
(minimum requirement 4)        −2,147,483,648 to 2,147,483,647
(minimum requirement)        0 to 4,294,967,295
(minimum requirement)
VB        Company Standard        Windows        Long        4 [7]        −2,147,483,648 to 2,147,483,647        N/A
VBA        Company Standard        Windows, Mac OS        Long        4 [8]        −2,147,483,648 to 2,147,483,647        N/A
SQL Server        Company Standard        Windows        BigInt        8        −9,223,372,036,854,775,808 to +9,223,372,036,854,775,807        0 to 18,446,744,073,709,551,615
.NET CLR/CTS        Company Standard        Windows        Long or Int64        8        −9,223,372,036,854,775,808 to +9,223,372,036,854,775,807        0 to 18,446,744,073,709,551,615
Java        International/Company Standard        Java platform        long        8        −9,223,372,036,854,775,808 to +9,223,372,036,854,775,807        N/A
Pascal         ?        Windows        int64        8        −9,223,372,036,854,775,808 to +9,223,372,036,854,775,807        N/A

bulaohu

果然是long int的问题，有不少long int的implementation到21亿就到头了

乱码

原帖由 bulaohu 于 2010-10-9 23:11 发表
果然是long int的问题，有不少long int的implementation到21亿就到头了

现在相当多的database primary key 都用guid,但用的不好，会有insert时page reshaffle的问题，和分布式数据库table和并pk冲突的问题，通常的做法是区自己网卡的mac地址，然后顺此递增。

bulaohu

原帖由 乱码 于 2010-10-9 23:41 发表


现在相当多的database primary key 都用guid,但用的不好，会有insert时page reshaffle的问题，和分布式数据库table和并pk冲突的问题，通常的做法是区自己网卡的mac地址，然后顺此递增。 ...

Server上可能严格一些，workstation上我在教育部工作的时候碰到过两次机器的MAC完全相同的情况，囧死个人