[prev in list] [next in list] [prev in thread] [next in thread]
List: cassandra-dev
Subject: Re: [DISCUSS] The future of CREATE INDEX
From: Caleb Rackliffe <calebrackliffe () gmail ! com>
Date: 2023-06-20 22:34:09
Message-ID: CAHvM0ud3w_4AcmBo-xMmTQp8r31eSFjHk6+W+8143Xsm9r3pMw () mail ! gmail ! com
[Download RAW message or body]
For everyone previously following this, just created
https://issues.apache.org/jira/browse/CASSANDRA-18615 :)
On Fri, May 19, 2023 at 1:34 PM Caleb Rackliffe <calebrackliffe@gmail.com>
wrote:
> Posted on ASF Slack to see if we can get more responses, but so far the
> leaders seem to be...
>
> [POLL] Centralize existing syntax or create new syntax?
>
> 1.) CREATE INDEX ... USING ... WITH OPTIONS...
>
> (i.e. centralize)
>
> [POLL] Should there be a default? (YES/NO)
>
> Yes
>
> [POLL] What do do with the default?
>
> 3.) and 4.) i.e. YAML options to control default and requirement to
> specify a default
>
> (i.e. w/o changing default in 5.0)
>
> On Thu, May 18, 2023 at 3:33 AM Miklosovic, Stefan <
> Stefan.Miklosovic@netapp.com> wrote:
>
> > I don't want to hijack this thread, I just want to say that the point 4)
> > seems to be recurring. I second Caleb in saying that transactional metadata
> > would probably fix this. Because of the problem of not being sure that all
> > config is same, cluster-wide, I basically dropped the effort on CEP-24
> > because different local configurations might compromise the security.
> >
> > ________________________________________
> > From: Henrik Ingo <henrik.ingo@datastax.com>
> > Sent: Wednesday, May 17, 2023 22:32
> > To: dev@cassandra.apache.org
> > Subject: Re: [DISCUSS] The future of CREATE INDEX
> >
> > NetApp Security WARNING: This is an external email. Do not click links or
> > open attachments unless you recognize the sender and know the content is
> > safe.
> >
> >
> >
> > I have read the thread but chose to reply to the top message...
> >
> > I'm coming to this with the background of having worked with MySQL, where
> > both the storage engine and index implementation had many options, and
> > often of course some index types were only available in some engines.
> >
> > I would humbly suggest:
> >
> > 1. What's up with naming anything "legacy". Calling the current index
> > type "2i" seems perfectly fine with me. From what I've heard it can work
> > great for many users?
> >
> > 2. It should be possible to always specify the index type explicitly. In
> > other words, it should be possible to CREATE CUSTOM INDEX ... USING "2i"
> > (if it isn't already)
> >
> > 2b) It should be possible to just say "SAI" or "SASIIndex", not the full
> > Java path.
> >
> > 3. It's a fair point that the "CUSTOM" word may make this sound a bit too
> > special... The simplest change IMO is to just make the CUSTOM work optional.
> >
> > 4. Benedict's point that a YAML option is per node is a good one... For
> > example, you wouldn't want some nodes to create a 2i index and other nodes
> > a SAI index for the same index.... That said, how many other YAML options
> > can you think of that would create total chaos if different nodes actually
> > had different values for them? For example what if a guardrail allowed some
> > action on some nodes but not others? Maybe what we need is a jira ticket
> > to enforce that certain sections of the config must not differ?
> >
> > 5. That said, the default index type could also be a property of the
> > keyspace
> >
> > 6. MySQL allows the DBA to determine the default engine. This seems to
> > work well. If the user doesn't care, they don't care, if they do, they use
> > the explicit syntax.
> >
> > henrik
> >
> >
> > On Wed, May 10, 2023 at 12:45 AM Caleb Rackliffe <
> > calebrackliffe@gmail.com<mailto:calebrackliffe@gmail.com>> wrote:
> > Earlier today, Mick started a thread on the future of our index creation
> > DDL on Slack:
> >
> > https://the-asf.slack.com/archives/C018YGVCHMZ/p1683527794220019<
> > https://urldefense.com/v3/__https://the-asf.slack.com/archives/C018YGVCHMZ/p168352 \
> > 7794220019__;!!PbtH5S7Ebw!YuQzuQkxC0gmD9ofXEGoaEmVMwPwZ_ab8-B_PCfRfNsQtKIZDLOIuw38jnV1Vt8TqHXn-818hL-CoLbVJXBTCWgSxoE$
> >
> > >
> >
> > At the moment, there are two ways to create a secondary index.
> >
> > 1.) CREATE INDEX [IF NOT EXISTS] [name] ON <table> (<column>)
> >
> > This creates an optionally named legacy 2i on the provided table and
> > column.
> >
> > ex. CREATE INDEX my_index ON kd.tbl(my_text_col)
> >
> > 2.) CREATE CUSTOM INDEX [IF NOT EXISTS] [name] ON <table> (<column>)
> > USING <class|alias> [WITH OPTIONS = <options>]
> >
> > This creates a secondary index on the provided table and column using the
> > specified 2i implementation class and (optional) parameters.
> >
> > ex. CREATE CUSTOM INDEX my_index ON ks.tbl(my_text_col) USING
> > 'StorageAttachedIndex'
> >
> > (Note that the work on SAI added aliasing, so `StorageAttachedIndex` is
> > shorthand for the fully-qualified class name, which is also valid.)
> >
> > So what is there to discuss?
> >
> > The concern Mick raised is...
> >
> > "...just folk continuing to use CREATE INDEX because they think CREATE
> > CUSTOM INDEX is advanced (or just don't know of it), and we leave users
> > doing 2i (when they think they are, and/or we definitely want them to be,
> > using SAI)"
> >
> > To paraphrase, we want people to use SAI once it's available where
> > possible, and the default behavior of CREATE INDEX could be at odds w/ that.
> >
> > The proposal we seem to have landed on is something like the following:
> >
> > For 5.0:
> >
> > 1.) Disable by default the creation of new legacy 2i via CREATE INDEX.
> > 2.) Leave CREATE CUSTOM INDEX...USING... available by default.
> >
> > (Note: How this would interact w/ the existing secondary_indexes_enabled
> > YAML options isn't clear yet.)
> >
> > Post-5.0:
> >
> > 1.) Deprecate and eventually remove SASI when SAI hits full feature
> > parity w/ it.
> > 2.) Replace both CREATE INDEX and CREATE CUSTOM INDEX w/ something of a
> > hybrid between the two. For example, CREATE INDEX...USING...WITH. This
> > would both be flexible enough to accommodate index implementation selection
> > and prescriptive enough to force the user to make a decision (and wouldn't
> > change the legacy behavior of the existing CREATE INDEX). In this world,
> > creating a legacy 2i might look something like CREATE INDEX...USING
> > `legacy`.
> > 3.) Eventually deprecate CREATE CUSTOM INDEX...USING.
> >
> > Eventually we would have a single enabled DDL statement for index
> > creation that would be minimal but also explicit/able to handle some
> > evolution.
> >
> > What does everyone think?
> >
> >
> > --
> >
> > [
> > https://lh5.googleusercontent.com/UwlCp-Ixn21QzYv9oNnaGy0cKfFk1ukEBVKSv4V3-nQShsR- \
> > cib_VeSuNm4M_xZxyAzTTr0Et7MsQuTDhUGcmWQyfVP801Flif-SGT2x38lFRGkgoMUB4cot1DB9xd7Y0x2P0wJWA-gQ5k4rzytFSoLCP4wJntmJzhlqTuQQsOanCBHeejtSBcBry5v6kw
> > ]
> >
> > Henrik Ingo
> >
> > c. +358 40 569 7354
> >
> > w. www.datastax.com<http://www.datastax.com>
> >
> > [
> > https://lh3.googleusercontent.com/T6MEp9neZySKd-eg-tkz96Yf4qG_Xsgu-IznDkdHfsHCjAnn \
> > HQP6OsPCdj8rsDvgKs-GJS6TA7Yx5HlK-zfRlE64j0zDpDG9cI29VaG948x5xLgUU4KKctaHNAhbpJ_pDwzRag9K7yCibGblB5Ix5z6Xj99Vc92V9nYSmR4HIj5F9T_TVI7ayW2n2_lp5Q
> > ]<https://www.facebook.com/datastax> [
> > https://lh3.googleusercontent.com/Xrju2UthJiMtMS5jFknV8AhVO45tfhXSR6U0F8Qam1Mu2taE \
> > 2SeVcl5ExaxU5l6pG0fHjv2b6vvUOe12WQldMqsOHknC7wQtBVYiX9ff3fLMtFAbjVRM0MGTKvPsjAcMI_FNvcIcuWIBP_zwRuh3b3g6hjHOW0ik9bDPuuYMvdLWIF8C8YgKDYQ-nV9dlQ]
> > <https://twitter.com/datastax> [
> > https://lh5.googleusercontent.com/OS41kMrzmJhmkvdmkHU-pq69Nzy1tOz36NIwGs61oz9cGj42 \
> > TTggsXk58MY1Lqn5FyIK77jedKh3UN-1RMCgCqduMQeUNU5fVKjCBNvSOpp6NjBLZp-2NMypQnw7JoyPoeI_iXfygfzquE89GLoel7Tiq1Jtz6ueaaVA9goEhUn2rWIJMQ28DPrEj4xqfg]
> > <https://www.linkedin.com/company/datastax/> [
> > https://lh3.googleusercontent.com/AVBOsupbzcVirw6fNWEIerGj-CT9XuzDmGpAa5KimxCLGAIC \
> > w7_TV040RngH0I_0Z9ZEWERsQOiCSqD4ORslxJdqFiuFc1qgIoA9QMXW_yRklRJrrrCO0rQ47Hvt9QtfAz7swR_Vn6N8wZPYE2APUJAo-oB_X71omearuZFBjL9VKbhbrZXn9HQ7aGSxIA]
> > <https://github.com/datastax/>
> >
> >
[Attachment #3 (text/html)]
<div dir="ltr">For everyone previously following this, just created <a \
href="https://issues.apache.org/jira/browse/CASSANDRA-18615">https://issues.apache.org/jira/browse/CASSANDRA-18615</a> \
:)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May \
19, 2023 at 1:34 PM Caleb Rackliffe <<a \
href="mailto:calebrackliffe@gmail.com">calebrackliffe@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
dir="ltr">Posted on ASF Slack to see if we can get more responses, but so far the \
leaders seem to be...<div><br></div><div><span style="color:rgb(80,0,80)"><div>[POLL] \
Centralize existing syntax or create new \
syntax?<br></div><div><br></div></span><div><font color="#000000">1.) CREATE INDEX \
... USING ... WITH OPTIONS...</font></div><div><font \
color="#000000"><br></font></div><div><font color="#000000">(i.e. \
centralize)</font></div><span style="color:rgb(80,0,80)"><div><font \
color="#000000"><br></font></div><div>[POLL] Should there be a default? (YES/NO)<font \
color="#000000"><br></font></div><div><font \
color="#000000"><br></font></div></span><div><font \
color="#000000">Yes</font></div><span style="color:rgb(80,0,80)"><div><font \
color="#000000"><br></font></div><div>[POLL] What do do with the default?<font \
color="#000000"><br></font></div><div><br></div></span><div><font color="#000000">3.) \
and 4.) i.e. YAML options to control default and requirement to specify a \
default</font></div></div><div><font color="#000000"><br></font></div><div><font \
color="#000000">(i.e. w/o changing default in 5.0)</font></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 18, 2023 at \
3:33 AM Miklosovic, Stefan <<a href="mailto:Stefan.Miklosovic@netapp.com" \
target="_blank">Stefan.Miklosovic@netapp.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I \
don't want to hijack this thread, I just want to say that the point 4) seems to \
be recurring. I second Caleb in saying that transactional metadata would probably fix \
this. Because of the problem of not being sure that all config is same, cluster-wide, \
I basically dropped the effort on CEP-24 because different local configurations might \
compromise the security.<br> <br>
________________________________________<br>
From: Henrik Ingo <<a href="mailto:henrik.ingo@datastax.com" \
target="_blank">henrik.ingo@datastax.com</a>><br>
Sent: Wednesday, May 17, 2023 22:32<br>
To: <a href="mailto:dev@cassandra.apache.org" \
target="_blank">dev@cassandra.apache.org</a><br>
Subject: Re: [DISCUSS] The future of CREATE INDEX<br>
<br>
NetApp Security WARNING: This is an external email. Do not click links or open \
attachments unless you recognize the sender and know the content is safe.<br> <br>
<br>
<br>
I have read the thread but chose to reply to the top message...<br>
<br>
I'm coming to this with the background of having worked with MySQL, where both \
the storage engine and index implementation had many options, and often of course \
some index types were only available in some engines.<br> <br>
I would humbly suggest:<br>
<br>
1. What's up with naming anything "legacy". Calling the current index \
type "2i" seems perfectly fine with me. From what I've heard it can \
work great for many users?<br> <br>
2. It should be possible to always specify the index type explicitly. In other words, \
it should be possible to CREATE CUSTOM INDEX ... USING "2i" (if it \
isn't already)<br> <br>
2b) It should be possible to just say "SAI" or "SASIIndex", not \
the full Java path.<br> <br>
3. It's a fair point that the "CUSTOM" word may make this sound a bit \
too special... The simplest change IMO is to just make the CUSTOM work optional.<br> \
<br> 4. Benedict's point that a YAML option is per node is a good one... For \
example, you wouldn't want some nodes to create a 2i index and other nodes a SAI \
index for the same index.... That said, how many other YAML options can you think of \
that would create total chaos if different nodes actually had different values for \
them? For example what if a guardrail allowed some action on some nodes but not \
others? Maybe what we need is a jira ticket to enforce that certain sections of the \
config must not differ?<br> <br>
5. That said, the default index type could also be a property of the keyspace<br>
<br>
6. MySQL allows the DBA to determine the default engine. This seems to work well. If \
the user doesn't care, they don't care, if they do, they use the explicit \
syntax.<br> <br>
henrik<br>
<br>
<br>
On Wed, May 10, 2023 at 12:45 AM Caleb Rackliffe <<a \
href="mailto:calebrackliffe@gmail.com" \
target="_blank">calebrackliffe@gmail.com</a><mailto:<a \
href="mailto:calebrackliffe@gmail.com" \
target="_blank">calebrackliffe@gmail.com</a>>> wrote:<br> Earlier today, Mick \
started a thread on the future of our index creation DDL on Slack:<br> <br>
<a href="https://the-asf.slack.com/archives/C018YGVCHMZ/p1683527794220019" \
rel="noreferrer" target="_blank">https://the-asf.slack.com/archives/C018YGVCHMZ/p1683527794220019</a><<a \
href="https://urldefense.com/v3/__https://the-asf.slack.com/archives/C018YGVCHMZ/p1683 \
527794220019__;!!PbtH5S7Ebw!YuQzuQkxC0gmD9ofXEGoaEmVMwPwZ_ab8-B_PCfRfNsQtKIZDLOIuw38jnV1Vt8TqHXn-818hL-CoLbVJXBTCWgSxoE$" \
rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://the-asf.slack.com \
/archives/C018YGVCHMZ/p1683527794220019__;!!PbtH5S7Ebw!YuQzuQkxC0gmD9ofXEGoaEmVMwPwZ_ab8-B_PCfRfNsQtKIZDLOIuw38jnV1Vt8TqHXn-818hL-CoLbVJXBTCWgSxoE$</a>><br>
<br>
At the moment, there are two ways to create a secondary index.<br>
<br>
1.) CREATE INDEX [IF NOT EXISTS] [name] ON <table> (<column>)<br>
<br>
This creates an optionally named legacy 2i on the provided table and column.<br>
<br>
ex. CREATE INDEX my_index ON kd.tbl(my_text_col)<br>
<br>
2.) CREATE CUSTOM INDEX [IF NOT EXISTS] [name] ON <table> (<column>) \
USING <class|alias> [WITH OPTIONS = <options>]<br> <br>
This creates a secondary index on the provided table and column using the specified \
2i implementation class and (optional) parameters.<br> <br>
ex. CREATE CUSTOM INDEX my_index ON ks.tbl(my_text_col) USING \
'StorageAttachedIndex'<br> <br>
(Note that the work on SAI added aliasing, so `StorageAttachedIndex` is shorthand for \
the fully-qualified class name, which is also valid.)<br> <br>
So what is there to discuss?<br>
<br>
The concern Mick raised is...<br>
<br>
"...just folk continuing to use CREATE INDEX because they think CREATE CUSTOM \
INDEX is advanced (or just don't know of it), and we leave users doing 2i (when \
they think they are, and/or we definitely want them to be, using SAI)"<br> <br>
To paraphrase, we want people to use SAI once it's available where possible, and \
the default behavior of CREATE INDEX could be at odds w/ that.<br> <br>
The proposal we seem to have landed on is something like the following:<br>
<br>
For 5.0:<br>
<br>
1.) Disable by default the creation of new legacy 2i via CREATE INDEX.<br>
2.) Leave CREATE CUSTOM INDEX...USING... available by default.<br>
<br>
(Note: How this would interact w/ the existing secondary_indexes_enabled YAML options \
isn't clear yet.)<br> <br>
Post-5.0:<br>
<br>
1.) Deprecate and eventually remove SASI when SAI hits full feature parity w/ it.<br>
2.) Replace both CREATE INDEX and CREATE CUSTOM INDEX w/ something of a hybrid \
between the two. For example, CREATE INDEX...USING...WITH. This would both be \
flexible enough to accommodate index implementation selection and prescriptive enough \
to force the user to make a decision (and wouldn't change the legacy behavior of \
the existing CREATE INDEX). In this world, creating a legacy 2i might look something \
like CREATE INDEX...USING `legacy`.<br> 3.) Eventually deprecate CREATE CUSTOM \
INDEX...USING.<br> <br>
Eventually we would have a single enabled DDL statement for index creation that would \
be minimal but also explicit/able to handle some evolution.<br> <br>
What does everyone think?<br>
<br>
<br>
--<br>
<br>
[<a href="https://lh5.googleusercontent.com/UwlCp-Ixn21QzYv9oNnaGy0cKfFk1ukEBVKSv4V3-n \
QShsR-cib_VeSuNm4M_xZxyAzTTr0Et7MsQuTDhUGcmWQyfVP801Flif-SGT2x38lFRGkgoMUB4cot1DB9xd7Y0x2P0wJWA-gQ5k4rzytFSoLCP4wJntmJzhlqTuQQsOanCBHeejtSBcBry5v6kw" \
rel="noreferrer" target="_blank">https://lh5.googleusercontent.com/UwlCp-Ixn21QzYv9oNn \
aGy0cKfFk1ukEBVKSv4V3-nQShsR-cib_VeSuNm4M_xZxyAzTTr0Et7MsQuTDhUGcmWQyfVP801Flif-SGT2x3 \
8lFRGkgoMUB4cot1DB9xd7Y0x2P0wJWA-gQ5k4rzytFSoLCP4wJntmJzhlqTuQQsOanCBHeejtSBcBry5v6kw</a>]<br>
<br>
Henrik Ingo<br>
<br>
c. +358 40 569 7354<br>
<br>
w. <a href="http://www.datastax.com" rel="noreferrer" \
target="_blank">www.datastax.com</a><<a href="http://www.datastax.com" \
rel="noreferrer" target="_blank">http://www.datastax.com</a>><br> <br>
[<a href="https://lh3.googleusercontent.com/T6MEp9neZySKd-eg-tkz96Yf4qG_Xsgu-IznDkdHfs \
HCjAnnHQP6OsPCdj8rsDvgKs-GJS6TA7Yx5HlK-zfRlE64j0zDpDG9cI29VaG948x5xLgUU4KKctaHNAhbpJ_pDwzRag9K7yCibGblB5Ix5z6Xj99Vc92V9nYSmR4HIj5F9T_TVI7ayW2n2_lp5Q" \
rel="noreferrer" target="_blank">https://lh3.googleusercontent.com/T6MEp9neZySKd-eg-tk \
z96Yf4qG_Xsgu-IznDkdHfsHCjAnnHQP6OsPCdj8rsDvgKs-GJS6TA7Yx5HlK-zfRlE64j0zDpDG9cI29VaG94 \
8x5xLgUU4KKctaHNAhbpJ_pDwzRag9K7yCibGblB5Ix5z6Xj99Vc92V9nYSmR4HIj5F9T_TVI7ayW2n2_lp5Q</a>]<<a \
href="https://www.facebook.com/datastax" rel="noreferrer" \
target="_blank">https://www.facebook.com/datastax</a>> [<a \
href="https://lh3.googleusercontent.com/Xrju2UthJiMtMS5jFknV8AhVO45tfhXSR6U0F8Qam1Mu2t \
aE2SeVcl5ExaxU5l6pG0fHjv2b6vvUOe12WQldMqsOHknC7wQtBVYiX9ff3fLMtFAbjVRM0MGTKvPsjAcMI_FNvcIcuWIBP_zwRuh3b3g6hjHOW0ik9bDPuuYMvdLWIF8C8YgKDYQ-nV9dlQ" \
rel="noreferrer" target="_blank">https://lh3.googleusercontent.com/Xrju2UthJiMtMS5jFkn \
V8AhVO45tfhXSR6U0F8Qam1Mu2taE2SeVcl5ExaxU5l6pG0fHjv2b6vvUOe12WQldMqsOHknC7wQtBVYiX9ff3 \
fLMtFAbjVRM0MGTKvPsjAcMI_FNvcIcuWIBP_zwRuh3b3g6hjHOW0ik9bDPuuYMvdLWIF8C8YgKDYQ-nV9dlQ</a>] \
<<a href="https://twitter.com/datastax" rel="noreferrer" \
target="_blank">https://twitter.com/datastax</a>> [<a \
href="https://lh5.googleusercontent.com/OS41kMrzmJhmkvdmkHU-pq69Nzy1tOz36NIwGs61oz9cGj \
42TTggsXk58MY1Lqn5FyIK77jedKh3UN-1RMCgCqduMQeUNU5fVKjCBNvSOpp6NjBLZp-2NMypQnw7JoyPoeI_iXfygfzquE89GLoel7Tiq1Jtz6ueaaVA9goEhUn2rWIJMQ28DPrEj4xqfg" \
rel="noreferrer" target="_blank">https://lh5.googleusercontent.com/OS41kMrzmJhmkvdmkHU \
-pq69Nzy1tOz36NIwGs61oz9cGj42TTggsXk58MY1Lqn5FyIK77jedKh3UN-1RMCgCqduMQeUNU5fVKjCBNvSO \
pp6NjBLZp-2NMypQnw7JoyPoeI_iXfygfzquE89GLoel7Tiq1Jtz6ueaaVA9goEhUn2rWIJMQ28DPrEj4xqfg</a>] \
<<a href="https://www.linkedin.com/company/datastax/" rel="noreferrer" \
target="_blank">https://www.linkedin.com/company/datastax/</a>> [<a \
href="https://lh3.googleusercontent.com/AVBOsupbzcVirw6fNWEIerGj-CT9XuzDmGpAa5KimxCLGA \
ICw7_TV040RngH0I_0Z9ZEWERsQOiCSqD4ORslxJdqFiuFc1qgIoA9QMXW_yRklRJrrrCO0rQ47Hvt9QtfAz7swR_Vn6N8wZPYE2APUJAo-oB_X71omearuZFBjL9VKbhbrZXn9HQ7aGSxIA" \
rel="noreferrer" target="_blank">https://lh3.googleusercontent.com/AVBOsupbzcVirw6fNWE \
IerGj-CT9XuzDmGpAa5KimxCLGAICw7_TV040RngH0I_0Z9ZEWERsQOiCSqD4ORslxJdqFiuFc1qgIoA9QMXW_ \
yRklRJrrrCO0rQ47Hvt9QtfAz7swR_Vn6N8wZPYE2APUJAo-oB_X71omearuZFBjL9VKbhbrZXn9HQ7aGSxIA</a>] \
<<a href="https://github.com/datastax/" rel="noreferrer" \
target="_blank">https://github.com/datastax/</a>><br> <br>
</blockquote></div>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic