标签：Dynamodb

一  各种删除方法的“坑”点：

先扫一盲，删除一个对象有下面一些风格：

Student.GroupKey id = new Student.GroupKey();
id.setParentId("321123"); //pk
id.setChildId("789");   //sk


//直接用ID删除
studentRepository.deleteById(id);

//直接用ID集批量删
studentRepository.deleteAllById(Arrays.asList(id));


Student student= new Student();
student.setId(id);

//直接删除"对象"

studentRepository.delete(student);


//批量删除"对象"集合
studentRepository.deleteAll(Arrays.asList(student));

这中间有3个关键点要注意：

（1）慎用studentRepository.deleteById(id);

因为它会先根据这个id来Query出对象，然后删除，如果查不到这个对象，则直接报错，但是我们的删除往往不需要这么低效，而且我们也很少关心要删除的对象存在与否，所以要慎用。参考代码：org.socialsignin.spring.data.dynamodb.repository.support.SimpleDynamoDBCrudRepository#deleteById

@Override
public void deleteById(ID id) {

   Assert.notNull(id, "The given id must not be null!");

   Optional<T> entity = findById(id);

   if (entity.isPresent()) {
      dynamoDBOperations.delete(entity.get());

   } else {
      throw new EmptyResultDataAccessException(String.format("No %s entity with id %s exists!", domainType, id),
            1);
   }
}

（2）studentRepository.deleteAllById(Arrays.asList(id));虽然有接口，但是还尚未实现，至少目前如此，巨坑。具体的错误如下：

2021-08-02 14:00:22.901 INFO 16600 --- [ main] e.d.DynamodbApplicationForDeleteImproved : Started DynamodbApplicationForDeleteImproved in 1.919 seconds (JVM running for 2.407)
Exception in thread "main" java.lang.IllegalArgumentException: No fragment found for method public abstract void org.springframework.data.repository.CrudRepository.deleteAllById(java.lang.Iterable)
at org.springframework.data.repository.core.support.RepositoryComposition$RepositoryFragments.lambda$findImplementationFragment$2(RepositoryComposition.java:537)
at java.base/java.util.Optional.orElseThrow(Optional.java:403)
at org.springframework.data.repository.core.support.RepositoryComposition$RepositoryFragments.findImplementationFragment(RepositoryComposition.java:537)
at java.base/java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:330)
at org.springframework.data.repository.core.support.RepositoryComposition$RepositoryFragments.invoke(RepositoryComposition.java:513)
at org.springframework.data.repository.core.support.RepositoryComposition.invoke(RepositoryComposition.java:285)
at org.springframework.data.repository.core.support.RepositoryFactorySupport$ImplementationMethodExecutionInterceptor.invoke(RepositoryFactorySupport.java:599)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
at org.springframework.data.repository.core.support.QueryExecutorMethodInterceptor.doInvoke(QueryExecutorMethodInterceptor.java:163)


（3）studentRepository.delete(student); 貌似很不好的方法，因为看起来需要先查询出整个student对象，实际并非如此，因为只需要构建出对象，把相关的Id传进去就可以了。实际删除请求构建的时候，压根不需要其他属性。参考下面的代码：

com.amazonaws.services.dynamodbv2.datamodeling.DynamoDBMapper#delete

@Override
public <T> void delete(T object, DynamoDBDeleteExpression deleteExpression, DynamoDBMapperConfig config) {
    config = mergeConfig(config);

    @SuppressWarnings("unchecked")
    Class<T> clazz = (Class<T>) object.getClass();
    final DynamoDBMapperTableModel<T> model = getTableModel(clazz, config);

    String tableName = getTableName(clazz, object, config);

    Map<String, AttributeValue> key = model.convertKey(object);
 
    //......
    DeleteItemRequest req = new DeleteItemRequest().withKey(key)
            .withTableName(tableName).withExpected(internalAssertions)
            .withRequestMetricCollector(config.getRequestMetricCollector());

    //......
    db.deleteItem(applyUserAgent(req));
}

其中“model.convertKey(object)”的实现如下：

public <H,R> Map<String,AttributeValue> convertKey(final T key) {
    final DynamoDBMapperFieldModel<T,H> hk = this.<H>hashKey();
    final DynamoDBMapperFieldModel<T,R> rk = this.<R>rangeKeyIfExists();
    return this.<H,R>convertKey(hk.get(key), (rk == null ? (R)null : rk.get(key)));
}

可见根本不需要其他属性。

（4）studentRepository.deleteAll(Arrays.asList(student)); 批量删除，没有啥好说的。同样，student仅需要传入Id就行了，无须其他属性，所以不需要先执行查询构建student这种操作（假设已经知道Id）。

总结：上述四种删除，很明显，假设只知道Id的情况下，单个删除用studentRepository.delete(student);多个删除用studentRepository.deleteAll(Arrays.asList(student)); 其他两种一种不能用，一种慎用。

二：假设一个表有2个key(pk + sk),如何仅仅用pk删除所有数据

实际上，这个问题对于其他数据库，例如Cassandra，不存在这个问题，但是对于Dynamodb本身，遇到双Key的表仅带Pk是没有办法删除数据的（不要问为啥，因为闭源），直接报错。此时如果想删除怎么办尼？只能先根据PK来找出所有的SK，然后批量使用PK + SK来删除对象。那这种通用的需求肯定已经有人实现过了。是的。在高版本的spring-data-dynamodb（低版本不支持的）中存在这样的删除方法支持。

你需要额外定义一个JPA方法：

void deleteByXXX(String id) //XXX是PK对应的变量名。

为什么需要额外定义：因为默认的org.springframework.data.repository.CrudRepository没有内置这个方法。

当我们定义后，一旦调用，会自动创建一个Query然后查询出数据集合，然后批量调用删除。这里可以可以参考关键代码：

class DeleteExecution implements QueryExecution<T, ID> {

@Override
public Object execute(AbstractDynamoDBQuery<T, ID> dynamoDBQuery, Object[] values) throws BatchDeleteException {
    List entities = dynamoDBQuery.doCreateQueryWithPermissions(values).getResultList(); //paged，有效的page
    List<DynamoDBMapper.FailedBatch> failedBatches = dynamoDBOperations.batchDelete(entities);
    //...... 
}

说到这里，你可能觉得这不就完事了么？但是这个是真正高效的删除方法么？考虑这点，我们需要衡量两个因素：
（1）在前文我们提到，删除需要知道所有的数据。而实际上仅仅知道PK和SK就足够了，不需要其他属性。而实际上一条记录，“大头”都是非key部分。所以衡量是否高效，我们要看它的查询是不是仅返回PK和SK就够了。实际上仅SK就够了。因为你是知道PK的不是么？
（2）当遇到大量数据的时候，我们需要衡量是不是上来把所有的数据全部加载到内存了再去删除。特别是在你没有查询结果仅包含ID的情况下。

了解了上面两个因素，我们来衡量下上面提及的方法是不是最好的。
（1）是不是查询仅返回rankey，其实可以@Query注解来约束，所以是我们自己要做的事情。如果不约束，很明显会读取所有的额外属性值的。可以参考下面的方法来设置：

   @Query(fields = "rangekeyname")
   void deleteByXXX(String id) //XXX是PK对应的变量名。

实现原理在于，当设置fields后，在发送请求时，会带上参数”ProjectionExpression”来告诉dynamodb仅返回指定的属性。
（2）遇到大量数据时，是否分批来删除，如果单纯看上述的“DeleteExecution”实现，你会觉得会分批的，毕竟“ dynamoDBQuery.doCreateQueryWithPermissions(values).getResultList()”正常返回的是PaginatedQueryList类型。
所以后面的删除会遍历这个PaginatedQueryList。而一旦遍历，就会按需自动加载后面的“页”。实际上就算不是遍历，直接get（index）也可能会自动按需加载后面的页：

    @Override
    public T get(int n) {
        checkUnsupportedOperationForIterationOnlyMode("get(int n)");
        
        while ( allResults.size() <= n && nextResultsAvailable() ) {
            moveNextResults(false);
        }

        return allResults.get(n);
    }

所以至少表明看，当删除大数据量内容，看起来是满足之前描述的要求的：分批获取rangeId，分批去删除，避免一次加载所有。但是实际测试、调试你会发现，事与愿违。可以查看下面的代码：

	@Override
	public List batchDelete(Iterable entities) {
		entities.forEach(it -> maybeEmitEvent(it, BeforeDeleteEvent::new)); ////这个地方把内容加载完毕了。

		List result = dynamoDBMapper.batchDelete(entities);

		entities.forEach(it -> maybeEmitEvent(it, AfterDeleteEvent::new));
		return result;
	}

在真正删除之前，会调用"entities.forEach(it -> maybeEmitEvent(it, BeforeDeleteEvent::new));", 它本来是好心做一些“发布事件”的。但是越误打误撞，在删除之前就直接把所有的内容全部加载完了。

所以综合起来看，spring-data-dynamodb提供的这个方法是不满足我们的理想条件的。

那么上述方法不符合条件时，我们是不是可以自己去实现，例如我们自己实现一个删除。不过此时，我们还需要实现一个get操作。所以大概率我们可能会直接使用JPA定义如下一个get方法来获取所有的rangekey集合：

   @Query(fields = "rangekeyname")
   List getByXXX(String id) //XXX是PK对应的变量名。

在上述代码中，返回的List实际也是PaginatedQueryList。此时我们再手工写一个不提前遍历的删除，例如如下：

	@Override
	public List batchDelete(Iterable entities) {
		List result = dynamoDBMapper.batchDelete(entities);
		return result;
	}

这样看起来好像实现了，前面获取一个PaginatedQueryList,然后中途没有遍历，所以没有提前记载，到删除的时候，会遍历，从而批量加载，然后以每25个元素一批来批量删除。但是实际上，如果你测试，你会发现又事与愿违，还是会在具体删除之前就所有的都加载了。那么问题出在那了？这里直接说下答案：List getByXXX(String id)会返回PaginatedQueryList，但是会提前把内容加载完，为啥？参考下面的代码：

org.springframework.data.repository.core.support.QueryExecutionResultHandler#requiresConversion

for (Object o : collection) 
	private boolean requiresConversion(Collection collection, Class expectedReturnType,
			@Nullable TypeDescriptor elementDescriptor) {

		if (Streamable.class.isAssignableFrom(expectedReturnType) || !expectedReturnType.isInstance(collection)) {
			return true;
		}

		if (elementDescriptor == null || !Iterable.class.isAssignableFrom(expectedReturnType)) {
			return false;
		}

		Class type = elementDescriptor.getType();

		for (Object o : collection) {  //提前一次性把内容加载完了。foreach本质也是调用迭代器。

			if (!type.isInstance(o)) {   
				return true;
			}
		}

		return false;
	}

当调用getByXXX时，我们在底层确实拿到了一个分页的结果集，当时spring data会把这个结果和我们方法定义的类型（这里就是List）进行比较，并按需转化。而即使你定义的也是集合类型，看道理不需要转，但是实际上，要不要转，对于集合类型而言，判断很特殊，即还要判断每个子元素要不要转。而这又会遍历PaginatedQueryList。导致提前把内容在删除前加载完了。

所以我们上述写的方案又被我们否决了。接下来的重点来了，那么我们怎么实现尼？我们可以避免完全使用spring-data-dynamodb来实现一个最优的版本：

首先获取结果参考下面的代码：

    private QueryRequest createQuery(String tableName, String rangeKey, HashMap keyConditions, int limit){
        QueryRequest queryRequest = new QueryRequest();
        queryRequest.setTableName(tableName);
        queryRequest.setKeyConditions(keyConditions);

/*        // old aws service interface, not allowed to co-existed with followed statements
        queryRequest.withAttributesToGet(rangeKey);*/

        // new aws service interface
        queryRequest.setSelect(Select.SPECIFIC_ATTRIBUTES);
        queryRequest.withProjectionExpression(rangeKey);

        queryRequest.withLimit(limit);

        return queryRequest;
    }

上面代码创建了一个QueryRequest，指定了仅获取rangekey。然后使用下面的代码来执行，并按批执行删除。

        QueryRequest queryRequest = createQuery(tableName, rangeKey, keyConditions, 200);
        QueryResult queryResult = amazonDynamoDB.query(queryRequest);

        deleteByQueryResult(hashKeyValue, rangeKey, queryResult);

        if (queryResult.getLastEvaluatedKey() == null) {
            return;
        }

        // handle for multi pages;
        while (queryResult.getLastEvaluatedKey() != null) {
            queryRequest.setExclusiveStartKey(queryResult.getLastEvaluatedKey());
            queryResult = amazonDynamoDB.query(queryRequest);
            deleteByQueryResult(hashKeyValue, rangeKey, queryResult);
        }

其中删除代码参考下面的：

    private void deleteByQueryResult(String hashKeyValue, String rangeKey, QueryResult queryResult) {
        List> items = queryResult.getItems();
        List toDeleteEntities = items.stream().map(getFunctionForConvertingToToDeletedObjects(hashKeyValue, rangeKey)).collect(Collectors.toList());
        deleteAll(toDeleteEntities);   //调用repository.deleteAll(toDeleteEntities);
    }

那么上面的方法，为什么就不会自动提前把所有rangid加载完尼？关键点在于，我们自己的实现，没有任何提前遍历的操作，构建删除对象的时候用的是“queryResult.getItems()”，这个并不会提前加载下一页。而是获取当前获取到的内容。

所以以上方法才是最优化的。不过这里注意下另外一件事，即我们显式设置了“queryRequest.withLimit(limit)”，这样的好处在于分页会更小，如果我们不显示指定的话，默认是以返回内容1M为分页的（AWS DYNAMODB自己控制的）。那说到这个limit设置，其实@Query注解也支持，用法如下：

   @Query(fields = "rangekeyname", limit = 5)
   List getByXXX(String id) //XXX是PK对应的变量名。

那么用上述方法，分页更小了，不过不要忘记，为啥不用上面的方法来获取？因为上述方法虽然分页小一些，但是还记得上面刚提的问题么？它会在删除前把内容全部加载完。也就是比如10000的数据，那最终虽然可能每5个一批获取，但是在删除之前，它还是获取完了这10000个数据的。

最好，再额外补充下，同时分页思想，删除需要的提前获取rangeid为啥不用Pageable这个Spring data自带的功能？例如下面这样：

@Query(fields = "objectId", limit = 5)
Page getByParentId(String parentId, Pageable pageable);

我们可以看下它的实现关键代码：

private Page createPage(List allResults, Pageable pageable, AbstractDynamoDBQuery dynamoDBQuery,
      Object[] values) {

   // Get the result = this list might be a lazy list
   Iterator iterator = allResults.iterator();

   // Check if the pageable request is 'beyond' the result set
   if (!pageable.isUnpaged() && pageable.getOffset() > 0) {
      long processedCount = scanThroughResults(iterator, pageable.getOffset());
      if (processedCount < pageable.getOffset()) {
         return new PageImpl<>(Collections.emptyList());
      }
   }

   // Then Count the result set size
   Query countQuery = dynamoDBQuery.doCreateCountQueryWithPermissions(values, true);
   long count = countQuery.getSingleResult();

   // Finally wrap the result in a page -
   if (!pageable.isUnpaged()) {
      // either seek to the proper part of the result set
      if (getResultsRestrictionIfApplicable() != null) {
         count = Math.min(count, getResultsRestrictionIfApplicable());
      }

      List results = readPageOfResultsRestrictMaxResultsIfNecessary(iterator, pageable.getPageSize());
      return new PageImpl<>(results, pageable, count);
   } else {
      // or treat the whole (lazy) list as the result page if it's unpaged
      return new UnpagedPageImpl<>(allResults, count);
   }
}

它不适合用来删除的“查询”主要有2点：
（1）每次查都会调用count();
（2）其中的scanThroughResults会“调过”之前的“页数”，等于要显示第3页的内容，要先加载完第1和第2页。

		private long scanThroughResults(Iterator iterator, long resultsToScan) {
			long processed = 0;
			while (iterator.hasNext() && processed < resultsToScan) {  //又是一个循环。
				iterator.next();
				processed++;
			}
			return processed;
		}

所以以删除为目的的需求，我们用page的思路明显“太重了”。

所以综合起来看，最高效的方法，目前还是需要自己去实现。不过反思下，为什么不提供出这样的方法尼？因为每一次的提前遍历都有特殊用途：发布事件或者判断要不要转化。而且这些遍历可能不是自己一个项目，例如判断转化是spring data的统一逻辑。
所以一不小心就提前加载了。不过话说回来，或许很少人去思考这些细节，毕竟功能都正常，简单想下看起来很好就结束了。

最后的文末，再说个相关的小插曲：

/*        // old aws service interface, not allowed to co-existed with followed statements
        queryRequest.withAttributesToGet(rangeKey);*/

        // new aws service interface
        queryRequest.setSelect(Select.SPECIFIC_ATTRIBUTES);
        queryRequest.withProjectionExpression(rangeKey);

仅获取部分属性时，上述2个字段都可行，但是不能同时设置，或者报错：

{"__type":"com.amazon.coral.validate#ValidationException","message":"Can not use both expression and non-expression parameters in the same request: Non-expression parameters: {AttributesToGet} Expression parameters: {ProjectionExpression}"}

通过上述研究，可见，删除一个东西在Dynamodb中并不方便，特别是仅有一个PK时，这点远不如Cassandra。