分享一个经历

03-09-02 iceant
谈一个我自己的经历,也就是上个星期的事。

上星期做的一个东东是基于 LDAP 的员工查询系统。几个月前我实现了这个模块,但是当时的实现是每次查询都要与 LDAP 做通讯,取出所有符合查询条件的记录,然后做分页计算,显示后就将记录集丢掉。一旦分页,又要做相同的操作。从这个实现上来看,效率是很低的。只是因为 LDAP 中员工的数据量有限(也就几K),而且我们使用的服务器的性能还算不错,查询本地员工的效率(1K 左右)就没有什么明显的停滞,用户也没有什么抱怨,于是我没有做什么优化。

但是近来,我开始用这个东东查询其它分公司的员工,发现在对整个 LDAP Tree 做查询时,效率非常低。而且服务器有限制,最多一次只能返回 2k 条数据。于是我开始想着怎么做优化。一开始我并没有看清楚自己应用的情况。我的应用其实分为两个部分,一个是查询,另一个是将 LDAP 中的数据全部导出。我当时认为无论是查询还是导出数据,它们的应用都是一样的,都是将满足某个条件的结果集列出,只是一个是分页显示,一个是全部列出。于是在做查询时,我也将满足要求的记录全数拿出做分页。这一次我做了 cache,对相同查询条件的结果集做了cache,做分页时的效率要比以前高,后来我想,从 LDAP 中取数据老是要经过网络,性能受限,对于大的结果集,传输量太大,于是我用 Lucene 做了一个 Index,每隔一段时间就在后台用 Thread 做 Index,同步两边的数居,在本地进行查询和处理的效率应该比经过网络要好。但是后来我很快就发现分页显示的查询应用是不需要返回一个大的结果集的,一方面用户做 pagination 操作时会很烦,而且这么大的数据量往往是无效信息过多,对用户毫无意义。另一方面出于对公司员工信息的保护,也不应该提供如此"便利"的功能,LDAP 服务器上2K条记录的限制是有意义的。

最后我还是取消了 Index 的功能,对于查询,我恢复成从网络取数据。一方面是这样的数据及时,第二个方面服务器之间可以走千兆网,效率不会比本地低多少。另外经过 cache 处理,尽管第一次查询效率慢,但是分页时的效率就很好了。最后就是不鼓励用户对大的数据量进行查询,如果可以选择,我宁愿把大数据量的查询做得更慢。

对于全部员工信息导出的功能,这是个受限功能,只有授权的人才能使用。这有一个经验可以分享一下,LDAP 中的 PagedResultsControl 可以用来获取所有的数据。

注: LDAP 有 VLV 扩展协议,但是因为我们的服务器不支持这种协议,所以我需要自己做分页计算。

这一次走了不少弯路,连 Index 我都已经实现了,最后才发现这样的功能不符合要求。做了不少的无用功。
总的来说,动手前应该先做设计,即使是在纸上简单的画一画,也可以使自己冷静下来,好好想想自己到底想要什么。

banq
2003-09-02 12:07
不错,顶一顶,这样的经验之谈是Jdon论坛最宝贵的财富。

Lucene相比数据库查询,我感觉优点在于全文两字,在个别关键字情况下,LDAP和数据库查询要方便,及时得多。

cute
2003-09-02 16:33
最近,我也想作一个收发文系统.我发现使用LDAP比较轻松一些.

mooncui
2003-09-03 14:05
很高兴看到这篇文章,我现在正在考虑是否用LDAP,我想问一下:
你一次提取2k条记录的速度是多少?
另外你说查询,LDAP提供哪些查询?
你在LDAP中记录一个对象的哪些属性?是不是只能记录最基本的几个属性,那如果有很多属性的话还是另外保存在数据库中?




shyguy
2003-09-03 14:43
有ldap-jdbc的

iceant
2003-09-03 16:52
TO: mooncui
我想你现在最城要的是对 LDAP 基本知识的了解。
建议你下载 LDAP 的相关协议看看,不用全看,你要做什么应用,就看什么。

另外 SUN 的网站上有 LDAP 的教材,就是 JNDI 的那一份。

>>你一次提取2k条记录的速度是多少?
提取 2K 条记录的速度我没有测试,不会很慢。

>>另外你说查询,LDAP提供哪些查询?
不清楚你要问什么,也许 rfc2254 和 rfc 2891 可以帮你弄清一些问题

>>你在LDAP中记录一个对象的哪些属性?是不是只能记录最基本的几个属性,那如果有很多属性的话还是另外保存在数据库中?

不需要数据库,LDAP 中可以存取任何信息,具体请看 LDAP 规范


mooncui
2003-09-04 09:06
我想我不会去研究LDAP的,其他有人研究LDAP,并做了封装,但好像不太好。
特别是在开发系统时,本身是要用数据库的,这样两个都要用了。
而且他们在LDAP中只保存最基本的信息,如组的关系,用户id,name,password,description。其他不保存,这样,在如果记录人员信息,就得在LDAP和数据库中都分别保存,通过id保持一致,而且对人员的查询,如果是组的关系就在LDAP中查,如果是属性方面的就在数据库中查,很是恶心。

那现在的问题是LDAP应该可以记录所有的属性的,如果这样是不是效率还是什么方面有问题?

hailwind
2003-09-04 17:50
>>>而且服务器有限制,最多一次只能返回 2k 条数据。

这个2K应该是JDBC驱动程序做的默认做的限制!不知你用的什么的驱动程序?

另外,你用什么的LDAP Server?

>>>另外经过 cache 处理,尽管第一次查询效率慢,但是分页时的效率就很好了。

你的cache处理是指什么呢?能否详细解释一下呢?

hailwind
2003-09-04 17:54
我曾经用java+ldap做邮件服务器系统的开发

其中一个管理功能就是把当前用户名列表,然后这个分页我纯用ldap根本就实现不了,最后只得用MySQL来配合才解决!

我的LDAP中有20多万条entry。

iceant
2003-09-04 22:26
TO: hailwind

>>我曾经用java+ldap做邮件服务器系统的开发,其中一个管理功能就是把当前用户名列表,然后这个分页我纯用ldap根本就实现不了

我不是很清楚你的应用情况,也许以下两个 LDAP 扩展协议可以帮你了解 LDAP 的功能:

VLV 扩展协议用来做分页显示是很简单的,但是需要服务器支持。我使用的 AD 服务器是支持的,但是管理员不肯帮我打开这个协议的支持。
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt

PagedResultsControl 则可以帮你从 LDAP 服务器中获取所有符合条件的记录。我将所有员工信息导出,就是使用的这个协议。
http://www.ietf.org/rfc/rfc2696.txt

据我所知 OpenLDAP/AD/Netscape LDAP Server 这几个流行的服务器都支持 VLV 和 PagedResultsControl 等扩展协议。所以这些功能都应该可以使用。

20 多万条的 Entry, 我建议你使用 VLV,因为这是专门用来为分页显示而设计的。

together
2003-09-09 14:07
好象OPENLDAP不支持 Simple Paged Result Control (RFC 2696)
http://www.openldap.org/faq/data/cache/649.html

iceant
2003-09-09 15:14
哦~~ 那肯定是我弄错了,谢谢你的指正。

liloboy
2003-10-16 19:10
================================================================
VLV 扩展协议用来做分页显示是很简单的,但是需要服务器支持。我使用的 AD 服务器是支持的,但是管理员不肯帮我打开这个协议的支持。
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt
================================================================
iceant,看来,你们公司的规模不小,官僚程度也不小!

liloboy
2003-10-16 19:21
谢谢分享经验,我n年以前用ASP写MIS的时候也碰到了这样的情况,拼命做分页程序,几乎通宵,结果第二天,用的人还说数据太多没什么用,当时的心情别说又有挫折了.不过回过来想想,也是自己的错觉,觉的技术是解决问题的唯一途径,实际上搞清楚用户需要什么才是最最重要的,当然如果技术障碍是用户需求的关键那对我是最好玩的.

说到底,还是喜欢这种感觉,钻研技术的感觉.

================================================================
谈一个我自己的经历,也就是上个星期的事。

上星期做的一个东东是基于 LDAP 的员工查询系统。几个月前我实现了这个模块,但是当时的实现是每次查询都要与 LDAP 做通讯,取出所有符合查询条件的记录,然后做分页计算,显示后就将记录集丢掉。一旦分页,又要做相同的操作。从这个实现上来看,效率是很低的。只是因为 LDAP 中员工的数据量有限(也就几K),而且我们使用的服务器的性能还算不错,查询本地员工的效率(1K 左右)就没有什么明显的停滞,用户也没有什么抱怨,于是我没有做什么优化。

但是近来,我开始用这个东东查询其它分公司的员工,发现在对整个 LDAP Tree 做查询时,效率非常低。而且服务器有限制,最多一次只能返回 2k 条数据。于是我开始想着怎么做优化。一开始我并没有看清楚自己应用的情况。我的应用其实分为两个部分,一个是查询,另一个是将 LDAP 中的数据全部导出。我当时认为无论是查询还是导出数据,它们的应用都是一样的,都是将满足某个条件的结果集列出,只是一个是分页显示,一个是全部列出。于是在做查询时,我也将满足要求的记录全数拿出做分页。这一次我做了 cache,对相同查询条件的结果集做了cache,做分页时的效率要比以前高,后来我想,从 LDAP 中取数据老是要经过网络,性能受限,对于大的结果集,传输量太大,于是我用 Lucene 做了一个 Index,每隔一段时间就在后台用 Thread 做 Index,同步两边的数居,在本地进行查询和处理的效率应该比经过网络要好。但是后来我很快就发现分页显示的查询应用是不需要返回一个大的结果集的,一方面用户做 pagination 操作时会很烦,而且这么大的数据量往往是无效信息过多,对用户毫无意义。另一方面出于对公司员工信息的保护,也不应该提供如此"便利"的功能,LDAP 服务器上2K条记录的限制是有意义的。

最后我还是取消了 Index 的功能,对于查询,我恢复成从网络取数据。一方面是这样的数据及时,第二个方面服务器之间可以走千兆网,效率不会比本地低多少。另外经过 cache 处理,尽管第一次查询效率慢,但是分页时的效率就很好了。最后就是不鼓励用户对大的数据量进行查询,如果可以选择,我宁愿把大数据量的查询做得更慢。

对于全部员工信息导出的功能,这是个受限功能,只有授权的人才能使用。这有一个经验可以分享一下,LDAP 中的 PagedResultsControl 可以用来获取所有的数据。

注: LDAP 有 VLV 扩展协议,但是因为我们的服务器不支持这种协议,所以我需要自己做分页计算。

这一次走了不少弯路,连 Index 我都已经实现了,最后才发现这样的功能不符合要求。做了不少的无用功。
总的来说,动手前应该先做设计,即使是在纸上简单的画一画,也可以使自己冷静下来,好好想想自己到底想要什么。

linyd_sun
2003-10-17 11:04
TO:iceant
我在win2000下装了个openldap服务,但是不知道怎样对目录进行操作:比如
插入、删除记录等,你能否指点一下 e-mail:sun_once@hotmail.com

2Go 1 2 下一页