Menu
▾
▴
Re: [Logicaldoc-devel] [Fwd: [WebDAV]Performance that Matters]
|
From: <m.m...@lo...> - 2008-10-21 08:42:20
|
> Hi there, > > i´m in trouble with my mind and want the same of you as from now :) > My topic belongs to WebDAV-Performance access where i currently work on. > > Access via WebDAV has one particular difference when we comparing dirctly with logicalDOC. By web we getting a much more straight forward path to a folder structure (and his content) using a unique number. Here its ld_menu.ld_id. The consequence is, that we can fairly fast accessing a appropriate folder by this approach. Indexing is adequate for use. > > WebDAV has no such feasability as we have no unqique id or something else for using a efficient index-access. An easy example: > > / (Root) > /My Images > /Documents > -|/... > -|/Bills/Something other/ > -|/... > > If we want going into the folder Bills(because we have something for pay and dont know the right folder at all) by starting over the root, we have to asking the DB six times for getting the right folder: > > / > /Documents > /Documents/Bills > > So we have a much more semantically access as an technically (as with IDs) procedure. The Problem is now, that we riding into a performance-farce when we looking at a use-case of 60.000 Documents anf folders or much more. > > What solutions exists? > > 1. No Changes > 2. Indexing FolderNames > 3. FolderTable > > 1) No Changes are good for us. Because we have to change nothing and can drinking a lot of whisky at the evening for relaxing and so on... But costumers/users getting rather angry when they have thousends > of documents to mange. Taking again the example above, we have to take 6(N^2 where N is the number of folders to the target-folder) times a full table scan on the ld_menu and on index-access. We need this count as we have getting at first the right folder (e.g. /Documents) and then the documents within the folder. > > 2) Indexing the name of the folder(ld_menu) attribute. Its on way, but ever DML on foldernames will be driving into a index-change which can cause transactional errors or performance-issues. I say, it can but its one way we can go without big changes and see in the future (or by costumer reports) whether this way turns into a much more inconvenienced situation. > > 3) Third possibility is to create a new table that holds ever folder path - and i mean an absolutly path - in the table. For Instance: > > ______PATH_____________________________________ID____ > /My Images ....................................1 > /My Images/Image Album I ......................2 > /My Images/Image Album I/thumbnails ...........3 > /Documents ....................................4 > > Every document is referencing to one ID. By WebDAV(and the usage is only for webdav or CIFS) we can passing the current path ino a sql-query and the db must take one FTS. The problems here are very wide-spreaded. For example, if we want to changing a folder that is positioned upon the middle (Image Album I) we have changing ID 2 and 3 for stay clear in the database. > > > Therefore i suggest the second point. > > Best Regards > Hi Gustav, many thanks for your very interesting considerations. First of all LogicalDOC must be able to handle up to 1 million documents(this is the reason for current refactorings) so we have to find a solution for WebDAV. Currently indexes stores document metadata and for each entry we have an attribute 'path' that saves the document's path(in term of folder ids), e.g.: /5/28/45/31 The index is kept updated each time a document changes. We are able to add another field let's say 'folders' populated with folder path like '/My Images/Image Album I/thumbnails' But each time we change a folder we have to update the index that may contain 1 million documents. This operation can be very problematic. I thik that the best solution is the third one and implemented as follows: 1. Create a table ld_pathid(ld_path,ld_folderId) 2. The MenuDAO updates this table each time a folder changes In this way the table ld_pathid is always updated and ready to use, the update operation is no so complex and above all changes in dolfer names are not so frequent as changes in documents. What do you think? --------------------------------------------------------------- ing. Marco Meschieri e-mail: m.m...@lo... <mailto:m.m...@lo...> --------------------------------------------------------------- Logical Objects snc Via Bonasi, 2/A 41012 Carpi (MO) Italy Tel./Fax. 059 688969 web: http://www.logicalobjects.it -- AVVERTENZE AI SENSI DEL DLGS 196/2003: Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i, sono da considerarsi strettamente riservate. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalita' inidcate nel messaggio stesso. Qualora riceveste questo messaggio senza esserne il destinatario Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellando dal vostro sistema; costituisce comportamento contrario ai principi dettati dal Dlgs196/2003 il trattenere il messaggio stesso, divulgandolo anche in parte, distribuirlo ad altri soggetti,copiarlo, od utilizzarlo per finalita'diverse. Titolare del trattamento e' Logical Objects SNC Via Bonasi 2/A 41012 CARPI (MO) Tel. 059/688969 Fax 059/688969 This e-mail and any file transmitted with it is intended only for the person or entity to which is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this e-mail by mistake, please notify us immediately by telephone or fax. Proprietor of treatment is Logical Objects SNC Via Bonasi 2/A 41012 CARPI (MO) Tel. 059/688969 Fax 059/688969 |
