Hash indexes can be O(1) in the best case, so I'd say between O(logN) and O(1). However direct access is always faster, even than Hash index when it's O(1).
Lvc@ ᐧ On 8 February 2015 at 22:12, Riccardo Tasso <[email protected]> wrote: > Aren't hash indexes O(1)? > > Riccardo > Il 08/feb/2015 21:08 "Luca Garulli" <[email protected]> ha scritto: > > Hi Rasmus, >> Indexes tend to be O(LogN), while RID is O(1). So it will always be >> faster. >> >> Lvc@ >> >> ᐧ >> >> On 8 February 2015 at 11:39, Rasmus Eneman <[email protected]> wrote: >> >>> Luca, bu using slugs in your URLs instead of database IDs you completely >>> remove this problem, as well as making your urls nicer and better for SEO. >>> >>> A question for people with good experience with OrientDB, what is the >>> performance implications with using slugs over rids if the slugs are >>> indexed? >>> Should I take care to keep a slug to rid mapping in for example redis so >>> that queries to OrientDB always uses rids? >>> >>> >>> On Wednesday, January 28, 2015 at 12:43:21 AM UTC+1, JR wrote: >>>> >>>> Thanks Riccardo, >>>> >>>> good point! do you know how others are solving this problem? I'm >>>> planning to use OrientDB as my only storage solution. >>>> >>>> Thanks a lot, >>>> Luca >>>> >>>> On Tuesday, January 27, 2015 at 3:39:54 PM UTC-8, Riccardo Tasso wrote: >>>>> >>>>> Yes Luca, >>>>> >>>>> consider also if you use rids in your URLs. For example: >>>>> http://myapp.com/details.jsp?rid=1:1 >>>>> >>>>> In this case if someone links to your URLs it could be a problem. >>>>> >>>>> Cheers, >>>>> Riccardo >>>>> Il 27/gen/2015 21:29 "Luca Rondanini" <[email protected]> ha >>>>> scritto: >>>>> >>>>>> Hi Andrey, >>>>>> >>>>>> just to double check, if I use RIDs in my web app everything should >>>>>> be fine. Inserts/updates won't change any RIDs. Problems may raise if, >>>>>> for >>>>>> example, I'm storing RIDs in MySQL as reference. If then, I export and >>>>>> reimport the data in orientDB the RIDs may be changed and the MySQL data >>>>>> won't reference the right rows anymore. >>>>>> >>>>>> Can you confirm? >>>>>> >>>>>> Thanks, >>>>>> Luca >>>>>> >>>>>> On Monday, January 19, 2015 at 5:28:16 AM UTC-8, Andrey Lomakin wrote: >>>>>>> >>>>>>> Hi Bertran, >>>>>>> The only issue is that if you do export database to JSON and then >>>>>>> back your RIDs will be changed. >>>>>>> But may be we will add option to keep rids on their places. Not so >>>>>>> hard to do. >>>>>>> The only downside of such flag will be presence of holes for rids of >>>>>>> removed records. >>>>>>> Each record removal consumes about 10 bytes of disk space (not so >>>>>>> much )) ), but when you do export/import we optimize space is used by >>>>>>> database as result rids may be changed. >>>>>>> >>>>>>> On Mon, Jan 19, 2015 at 2:48 PM, Bertrand Quenin < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm currently using OrientDB for a project at work and I have some >>>>>>>> question about record IDs. >>>>>>>> >>>>>>>> As far as I understood, record IDs are unique and can be used to to >>>>>>>> identify a record in a deterministic way. I was wondering if these IDs >>>>>>>> can >>>>>>>> be used to identify objects through (REST) APIs. >>>>>>>> >>>>>>>> As any web application, I need to identify objects one way or >>>>>>>> another and I was wondering what the best approach would be: >>>>>>>> 1/ Using record IDs provided by orient DB >>>>>>>> 2/ Adding a "business" id field to my objects and manage it aside. >>>>>>>> >>>>>>>> So far, I didn't see any reason why I shouldn't use the record ID >>>>>>>> itself, the only con I see is that RID are strings clusterId#position >>>>>>>> (and >>>>>>>> not plain integers) and it's a bit harder to expose in an URL ... >>>>>>>> >>>>>>>> Is there any issue I haven't foresee ? >>>>>>>> >>>>>>>> Thanks for your help >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> --- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "OrientDB" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Andrey Lomakin. >>>>>>> >>>>>>> -- >>>>>> >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "OrientDB" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OrientDB" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OrientDB" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
