最近有个网友在做gps的一个系统。简单的讲就是,系统接收卫星传回的每辆车的数据,并保存这些数据供以后查询。每条数据的包含信息一般由*MID,CMD,F,DATA#构成。'*'为开头(1个字节),'#'为结尾 (1个字节)。下面就是一条示例数据:
*000000,00,00,155705,A,2202.12,11307.001,10,0,211209#
车ID:000000(MID,6个字节)
命令标示:00(CMD,2个字节)
状态标示:00(超速报警,防盗报警。。。)(F,2个字节)
卫星时间(时分秒:155705)15:57:05(6个字节)
数据是否有效(A有效,V无效)(1个字节)
维度:2202.12
经度:11307.001
速度:10
方向:0(0-360)
卫星时间:(日月年211209)09-12-21 (6个字节)
每辆车大约每40秒有一条数据,一天大约有2000条记录。整个系统由多个服务器组成,设计要求是每台服务器大约负担5万辆车半年的数据插入存储和查询。这就是每天有1亿条数据插入,而且还要不经常查询这个系统实际上是网友(qq号是63731???放飞)的一个系统。他目前是用sql server 做数据存储的。采用定时bcp的方式来处理的,在存储上每个数据库服务器只能负担1万到2万左右的车辆,达不到服务器负担5万辆车的设计要求。其实只考虑bcp数据插入,用sql server 是可以承受更多的数据插入的,但是还要保证数据查询不要过慢,所以我的那个网友最好只好每台服务器负责1万辆车的数据了。他目前的系统每分钟只能提供100次的查询。这也是他最后决定每台服务器只负责1万辆车的原因。经过我对这个系统的分析后,我做了一些改动和优化,试每台服务器可以达到5万辆车的数据存储,数据查询上也达到了每分钟1500-2000次)查询左右。这个速度是5万辆车中随机不同的车号的查询,如果是同一车号的不同时间的查询,可以达到每分钟1万次以上。基本上就测试结果来看,在数据插入变为原来的5倍的情况下,查询也提高了10倍以上。下面我开始说说,我是如何处理的,我的方法其实不是一个好的方法,也没有用任何技术,用的写法是任何一个大学二年级的学生都曾经写过的写法(甚至是非计算机系的学生)。我为什么采用这种写法的原因是:我很懒,而且这种写法也刚好可以达到设计要求。
第一步,解析数据
所有数据是通过udp从卫星上收下来的,很多条保存成一个文本文件,然后交给负责数据插入的程序处理。这种写法为什么是这样,还有为什么是变长的文本数据而不是定长的2进制数据,这个只能说是个历史遗留问题。其实在做项目时,经常遇到很多旧的程序,有时要兼容这些是必须的。先分析原来的程序的写法,他原来的写法用的是下面这个函数
function Split(aValue: string; aDelimiter: Char; StringList: TStrings): string;
var
X: Integer;
S: string;
begin
if StringList = nil then
StringList := TStringList.Create;
StringList.Clear;
S := '';
for X := 1 to Length(aValue) do
begin
if aValue[X] <> aDelimiter then
S := S + aValue[X]
else begin
S := S + aDelimiter;
StringList.Add(TrimLeft(S));
S := '';
end;
end;
Result := S;//未处理的数据
end;
其实这个函数比较中规中矩(后来和网友聊,据说这个也是我随手写给他的,不过我忘记了)。好了我们开始改这里吧。我有个不好的习惯就是不喜欢用string,尤其不喜欢字符串相加。上边的那个函数好像也是我写的,估计那是急着去洗手间的时候写的。下面就是新的代码了。调用的代码为ReadReciveData(ms_text.Memory, ms_text.Position, ms_dat, ReciveData);其中 ms_text和 ms_dat是TMemoryStream对象。
TGetReciveDataProc = procedure(const obj: Pointer; const ReciveData: TReciveData) of object;
function ReadReciveData(buf: pchar; len: integer; obj: Pointer; Proc: TGetReciveDataProc): integer;
var
i, begin_i, ReciveData_bufflen: integer;
p, begin_p: PChar;
ReciveData: TReciveData;
begin
{ 解析文本 速度还可以 2009-12-23
begin_Char: char = '*';
end_Char: char = '#';
}
Result := 0;
begin_p := nil;
p := buf;
for i := 1 to len do
begin
if p^ = begin_Char then
begin
begin_p := p;
begin_i := i;
end
else
begin
if p^ = end_Char then
begin
if begin_p <> nil then
begin
inc(begin_p); //跳过 begin_Char
ReciveData_bufflen := i - begin_i - 1; //去掉 begin_Char 和 end_Char
ProcReciveData(begin_p, ReciveData_bufflen, ReciveData);
//解析文本 *000000,00,00,155705,A,2202.12,11307.001,10,0,211209#
Proc(obj, ReciveData);
Result := i; //返回值是 处理的字节数
begin_p := nil;
end;
end;
end;
inc(p);
end;
end;
回调函数Proc是
procedure TFrm_dataInserter.ReciveData(const obj: Pointer;
const ReciveData: TReciveData);
var
ms: TMemoryStream;
begin
//处理报警信息。。。
ms := TMemoryStream(obj);
ms.Write(ReciveData, sizeof(ReciveData));
end;
这个函数没有使用字符串。速度比原来的快了很多,而且基本不占用内存。其实,很久以前用C语言时就这样写了,这样写也是一种怀旧吧。字符串相加实际上是一个比较讨厌的事情,但是你写代码时要经常遇到。一般的情况下,我也是直接相加。只有对速度有特殊要求是我才会用其他写法。这个主要是因为字符串相加时需要重新分配内存,这就会影响速度。顺便说一下,我现在用C#,C#的Stringbuilder就是为了干这个事的,不过他比较凶狠,当实际的内容超出内存空间,他往往分配2倍大小内存。这一点也验证了“要想快,开内存”(貌似有“要想富,圈地皮”的嫌疑)的思想。在处理大量文本时,我的想法是,尽量用PChar来减少字符串传递,不过要慎重。一般情况下没必要这样写。我们在来看看ProcReciveData。这个函数是提取文本里的具体数据的,这里我一样没有用string,基本的写法和ReadReciveData相似,不过这里用了一个自己写的函数fromHex。
procedure ProcReciveData(buf: pchar; len: integer; var ReciveData: TReciveData);
var
p, begin_p: PChar;
i, dataIdx, begin_i, data_len: integer;
AYear, AMonth, ADay, AHour, AMinute, ASecond: Word;
dt: TDateTime;
tmp_p: array[0..16] of char;
begin
p := buf;
begin_p := p;
begin_i := -1;
dataIdx := 0;
for i := 1 to len do
begin
if (p^ = Separator_Char) or (i = len) then // Separator_Char: char = ',';
begin
data_len := i - begin_i;
case dataIdx of
0: Move(begin_p[0], ReciveData.MID, MID_len); //车ID(MID,6个字节)
1: Move(begin_p[0], ReciveData.CMD, CMD_len); //命令标示(CMD,2个字节)
2: ReciveData.TrackData.status := fromHex(begin_p, 2); //状态标示(超速报警,防盗报警。。。)(F,2个字节)
3:
begin //155705:卫星时间(时分秒)15:57:05(6个字节)
AHour := from10(begin_p, 2);
inc(begin_p, 2);
AMinute := from10(begin_p, 2);
inc(begin_p, 2);
ASecond := from10(begin_p, 2);
end;
4: ReciveData.TrackData.valid := begin_p^; // A:数据是否有效(A有效,V无效)(1个字节)
5:
begin //维度
Move(begin_p[0], tmp_p[0], data_len);
tmp_p[data_len] := #0;
TextToFloat(tmp_p, ReciveData.TrackData.location.Dimension, fvCurrency)
end;
6:
begin //经度
Move(begin_p[0], tmp_p[0], data_len);
tmp_p[data_len] := #0;
TextToFloat(tmp_p, ReciveData.TrackData.location.Longitude, fvCurrency)
end;
7: ReciveData.TrackData.speed := from10(begin_p, data_len); //速度
8: ReciveData.TrackData.Direction := from10(begin_p, data_len); //方向(0-360)
9:
begin //211209:卫星时间(日月年)09-12-21 (6个字节)
ADay := from10(begin_p, 2);
inc(begin_p, 2);
AMonth := from10(begin_p, 2);
inc(begin_p, 2);
AYear := from10(begin_p, 2) + 2000;
end;
end;
inc(dataIdx);
begin_i := -1;
end
else
begin
if begin_i < 0 then
if p^ <> ' ' then
begin
begin_p := p;
begin_i := i;
end;
end;
inc(p);
end;
if not TryEncodeDateTime(AYear, AMonth, ADay, AHour, AMinute, ASecond, 0, ReciveData.TrackData.SatelliteTime) then
ReciveData.TrackData.SatelliteTime := now;
end;
fromHex这个函数实际上就是strtoint('$'+'FF'),只是速度快一点而已。这个函数实际上就是一个查表法的计算。其实这里没必要用这个写法,因为这里用fromHex还是用strtoint 对于整个项目而言占的比重太小了。
var
Hex_Table: array[#0..#$FF] of Byte;
procedure init_Hex_Table;
var
i: integer;
ch: Char;
begin
for ch := #0 to #$FF do
Hex_Table[ch] := 0;
for ch := '0' to '9' do
Hex_Table[ch] := StrToInt('$' + ch);
for ch := 'a' to 'f' do
Hex_Table[ch] := StrToInt('$' + ch);
for ch := 'A' to 'F' do
Hex_Table[ch] := StrToInt('$' + ch);
end;
function fromHex(v: PChar; len: integer): Byte;
var
i: integer;
p: PChar;
begin
p := v;
Result := 0;
for i := 1 to len do
begin
Result := Result * 16 + Hex_Table[p^];
inc(p);
end;
{
这种写法 只是 为了追求速度 2009-12-24
比 StrToInt 快40%
比 StrToInt('$'+s) 快20倍 左右
}
end;
进程加载后要调用init_Hex_Table,初始化Hex_Table,代码如下
initialization
begin
init_Hex_Table;
end;
end.
这样的写法以前在单片机上经常见到,有些比较追求速度的计算也用查表法,例如CRC校验的计算。说白了就是预计算和缓存结果。有时候查表法确实是不错的选择。到这里基本就对解析数据优化完了,单以解析数据而言,修改后的代码比原来的代码快不少具体多少我没测试,至少快5倍以上吧。因为解析这些文本文件,在整个流程中占得比重很小,所以我就随便改改了。
08-21
08-21
08-21
03-27