Дизайн схемы Кассандры

Ниже я определил модель данных, но проще сначала описать объектную модель, а затем погрузиться в модель строк, поэтому с точки зрения PlayOrm у вас будет

public class Student {
  @NoSqlId
  private String id;
  private String firstName;
  private String lastName;
  @ManyToMany
  private List<Course> courses = new ArrayList(); //constructing avoids nullpointers
}

public class Course {
  @NoSqlId
  private String id;
  private String name;
  private String description
  @ManyToOne
  private Lecturer lecturer;
  @ManyToMany
  private CursorToMany students = new CursorToManyImpl();
}

Я мог бы использовать список в курсе, но я был обеспокоен тем, что могу получить OutOfMemory, если слишком много студентов будут проходить курс годами, годами и годами. ТЕПЕРЬ давайте перейдем к тому, что делает PlayOrm, и вы можете сделать что-то подобное, если хотите.

Один студенческий ряд будет выглядеть так

rowKey(the id in above entity) = firstName='dean',
lastName='hiller' courses.rowkey56=null, courses.78=null, courses.98=null, courses.101=null

Это широкая строка, в которой у нас есть много столбцов с именем «имя поля» и «ключ строки к фактическому курсу».

Строка «Курс» немного интереснее… потому что пользователь думает, что загрузка всех «Студентов» для одного курса может привести к нехватке памяти, он использует курсор, который загружает только 500 за раз, когда вы зацикливаетесь на нем.

В этом случае у PlayOrm есть две строки, поддерживающие курс. Итак, давайте возьмем нашу строку пользователя выше, и он был в курсе rowkey56, поэтому давайте опишем этот курс

rowkey56 = name='coursename', description='somedesc', lecturer='rowkey89ToLecturer'

Затем в некоторой индексной таблице есть еще одна строка для студентов (это очень широкая строка, поэтому она поддерживает до миллионов студентов).

indexrowForrowkey56InCourse = student34.56, student39.56, student.23.56.... 
into the millions of students

Однако, если вы хотите, чтобы курс посещали более миллиона студентов, вам нужно подумать о разделении независимо от того, используете ли вы playOrm или нет. Однако PlayOrm делает для вас разбиение, если вам это нужно.

ПРИМЕЧАНИЕ. Если вы не знаете спящий режим или JPA, когда вы загружаете вышеприведенный Student, он загружает список прокси-серверов, поэтому, если вы начнете перебирать курсы, он затем вернется в хранилище noSQL и загрузит курсы, чтобы вы не придется ;).

В случае с курсом загружается прокси-лектор, который не заполняется до тех пор, пока вы не получите доступ к полю свойства, такому как лектор.getName(). Если вы вызываете лектор.getId(), ему не нужно загружать лектора, так как он уже есть из строки курса.

РЕДАКТИРОВАТЬ (подробнее): PlayOrm имеет 3 таблицы индексов Decimal (хранит двойные, плавающие и т. Д. И BigDecimal), Integer (длинные, короткие и т. д., BigInteger и логические) и таблицы индексов String. Когда вы используете CursorToMany, он использует одну из этих таблиц в зависимости от типа ключа FK. Он также использует эти таблицы для своего языка Scalable-SQL. Причина, по которой он использует отдельную строку в CursorToMany, заключается в том, что клиенты не получают OutOfMemory при чтении строки, поскольку в некоторых случаях toMany может иметь один миллион FK. Затем CursorToMany считывает пакеты из этой строки индекса.

позже, Дин